[D] DCC mit Mikrocontroller auslesen
Jochen Dolze
wo gibt es Projekte/Produkte mit denen man lediglich das DCC-Protokoll
mitlesen kann, d.h. sozusagen ein DCC-doityourself-Kit für den weiteren
Ausbau (damit nicht jeder bei Adam und Eva anfangen muss).
Ich denke da an eine uController-Lösung inkl. Programm, die eben die
Datenbits des DCC-Protokolls irgendwo im Speicher ablegt. Nun kann man
das Programm erweitern und aufgrund der DCC-Daten Aktionen durchführen.
Größe spielt keine Rolle, das soll nicht in das rollende Material, d.h.
es muss nix hochtechnologisches sein.
Gruß
Jochen
Manfred Richter
wenn Du nicht unbedingt auf ein uC - Lösung hinaus willst dann solltest Du
Dir mal den DCC - Sniffer hier anschauen:
http://www.digitoys-systems.com/ShowDCC_e.htm
Man muss noch ein paar Bauteile zusammenlöten und an die Soundkarte des PC
anschliessen und schon kann man schön mitlesen - läuft bei mir astrein ;-)
http://www.amhamberg.de
Grüsse,
Manfred
"Jochen Dolze" <der_...@dolze.de> schrieb im Newsbeitrag
news:35famlF...@individual.net...
Manfred Richter
den Atmel etwas unter http://bahn-in-haan.de , http://www.amhamberg.de und
für PIC's (nicht zu empfehlen, hehe) hier was:
http://www.merg.org.uk/resources/dcc.htm
Ist meist mit Schaltplan, Layout und Programm, z.T. auch mit Sourcen.
--
Grüsse,
Manfred Richter
http://www.amhamberg.de
"Jochen Dolze" <der_...@dolze.de> schrieb im Newsbeitrag
news:35famlF...@individual.net...
Bernhard Baptist
<der_...@dolze.de>:
> Hallo NG,
>
> wo gibt es Projekte/Produkte mit denen man lediglich das DCC-Protokoll
> mitlesen kann, d.h. sozusagen ein DCC-doityourself-Kit für den weiteren
> Ausbau (damit nicht jeder bei Adam und Eva anfangen muss).
Servus
Ich stand vor zwei Wochen vor genau der selben Frage :-)
Informationen und Projekte gibts im Web ja einige, allerdings leider
größtenteils ohne Sourcecode.
Einige Quellen wurden ja schon genannt.
Ich wollte aber meinen EIGENEN Decoder, und nicht bloß fertige Projkte
nachbauen.
Drum hab ich mich dann drangemacht um mir den Code halt doch selbst zu
schreiben.
So wie von dir treffend erwähnt, begin bei Adam&Eva. ist aber gar nicht
schwer, auf
http://www.nmra.org/standards/consist.html#standards-DCC ist alles
wunderbar documentiert.
Inzwischen geht schon recht gut.
DCC-Telegramme kann ich nun halbwegs zuferlässig decodieren. Arbeite in
diesen Minuten an der Verfeinerung.
Dann kommt die Ansteuerung der Peripherie - als erstes soll es ein
Weichendecoder werden.
Hardware ist soweit ganz simpel, da sind keien großen Tricks notwendig.
Als Basis hab ich mir einen AVR Mega8 (später ein Tiny2313) mit
Bascom-Compiler ausgesucht. Zum Testen hab ich die Intellibox.
Bin jederzeit an Erfahrungsaustausch interesiert.
gruß
bb
--
Für Emailantwort bitte das xxx in der Adresse mit "bernhard.baptist"
ersetzen. Der Spam wird sonst einfach zu viel.
Visit my Homepage: www.carinthians.com/bb
Manfred Richter
Du hast tatsächlich in einen AT2313 mit Bascom einen DCC - Decoder
reingebracht? Respekt - wieviel Platz hast Du da noch? Ich habe das relativ
schnell aufgegeben und bin auf Assembler umgestiegen...
"Bernhard Baptist" <x...@carinthians.com> schrieb im Newsbeitrag
news:opsk0lj6...@buero.arbeitsgruppe...
Bernhard Baptist
<bla...@amhamberg.de>:
> Hallo,
> Du hast tatsächlich in einen AT2313 mit Bascom einen DCC - Decoder
> reingebracht? Respekt - wieviel Platz hast Du da noch? Ich habe das
> relativ
> schnell aufgegeben und bin auf Assembler umgestiegen...
zzt, spiele ich noch mit de Mega8, Ziel ist aber dann der 2313.
So wie es aussieht sollte sichs schon ausgehen.
Matthias Kordell
> Falls Du natürlich doch mit uC's etwas machen willst, dann findest
> Du für den Atmel etwas unter http://bahn-in-haan.de ,
> http://www.amhamberg.de
Hmm, das sind alles nur Weichendecoder. Gibt es auch sowas für
Lokdecoder?
Matthias
--
Achtung: Dieses Posting kann Ironie und Sarkasmus enthalten!
Matthias Kordell
> Du hast tatsächlich in einen AT2313 mit Bascom einen DCC - Decoder
> reingebracht? Respekt - wieviel Platz hast Du da noch? Ich habe das
> relativ schnell aufgegeben und bin auf Assembler umgestiegen...
Ich will erst mal mit einem ATMega16 anfangen zu experimentieren,
der sollte ausreichend Platz bieten. Gibt es irgendwo auch Projekte
für gcc?
Jens Schmidt
Nicht nur das Protokoll, sondern komplette Lokdecoder mit Hard- und Software
gibt es von Georg Ziegler unter
http://www.fremo.utwente.nl/selfmade_decoder/
Das sollte auf die gewünschten Zwecke anpassbar sein. Die Größe ist übrigens
auch beachtlich.
--
Viele Grüße,
Jens Schmidt
Stefan Sczekalla
> Als Basis hab ich mir einen AVR Mega8 (später ein Tiny2313) mit
> Bascom-Compiler ausgesucht. Zum Testen hab ich die Intellibox.
du decodierst DCC mit Compiliertem Basic - das geht ?
Staun !!!
Kannst Du da mehr drüber schreiben ?
ich bin gerade dabei mir ne "art" Spezialweichendekoder" zu bauen um hier
eine "große" Schiebebühne ( 10 Gleise werden im Schatten bahnhof
"verschoben " ) anzusteuern.
Im moment habe ich mich dafür entschieden meine Schiebebühne per M*
Protokoll anzusteuern - per Hardwaredecoder (MC145027) der dann die
decodierte info an eine ATMega weitergibt weil ich mich um den
Zeitaufwand herumdrücken will das mm oder dcc signal direkt zu decodieren
...
Grüße,
Stefan
Bernhard Baptist
<use...@warez.game-server.cc>:
> Manfred Richter tut geschreibselt haben:
>
>> Falls Du natürlich doch mit uC's etwas machen willst, dann findest
>> Du für den Atmel etwas unter http://bahn-in-haan.de ,
>> http://www.amhamberg.de
>
> Hmm, das sind alles nur Weichendecoder. Gibt es auch sowas für
> Lokdecoder?
>
Ein Decoder mit Lastregelung und allem Schnickschnack dürfte schon eine
heftige Herausforderung sein.
Zum üben und fürn Anfang sollte ein Zubehördecoder wohl genug
heraqusforderung bieten.
Einen ungeregelten kann man ja relativ leicht aus einem Weichendecoder
ableiten.
Die Datenbits haben ein bisl andere Bedeutung, dann noch eine PWM (da
gibts im Netz bsp. ohne ende) hinten dran, eine Endstufe und fertig.
Bernhard Baptist
<stefan.s...@gmx.de>:
> Hallo Bernhard,
>
>
>> Als Basis hab ich mir einen AVR Mega8 (später ein Tiny2313) mit
>> Bascom-Compiler ausgesucht. Zum Testen hab ich die Intellibox.
>
> du decodierst DCC mit Compiliertem Basic - das geht ?
>
> Staun !!!
>
> Kannst Du da mehr drüber schreiben ?
Verwende die hier beschriebene Mehthode, ist gar nicht so kompliziert.
Leider wollte der Autor seinen Sourcecode nicht weitergeben, so muß ich
mich halt selbst versuchen.
Er hat die Vorgangsweise auf seiner Seite super beschrieben.
Matthias Kordell
> > Manfred Richter tut geschreibselt haben:
> >
> >> Falls Du natürlich doch mit uC's etwas machen willst, dann
> >> findest Du für den Atmel etwas unter http://bahn-in-haan.de ,
> >> http://www.amhamberg.de
> >
> > Hmm, das sind alles nur Weichendecoder. Gibt es auch sowas für
> > Lokdecoder?
>
> Ein Decoder mit Lastregelung und allem Schnickschnack dürfte schon
> eine heftige Herausforderung sein.
Ich dachte eher an einen Decoder für Drehstrommotoren (open loop),
bei Synchronmotoren braucht man dann keine Regelung mehr, man darf
halt nur das max. Drehmoment nicht überschreiten, aber das sollte im
Modell sowieso kaum möglich sein. Sollte man es doch schaffen, muss
man allerdings neu anfahren...
> Zum üben und fürn Anfang sollte ein Zubehördecoder wohl genug
> heraqusforderung bieten.
> Einen ungeregelten kann man ja relativ leicht aus einem
> Weichendecoder ableiten.
> Die Datenbits haben ein bisl andere Bedeutung, dann noch eine PWM
> (da gibts im Netz bsp. ohne ende) hinten dran, eine Endstufe und
> fertig.
Bei einer Drehstrom-Endstufe braucht man das ganze 1,5fach und muss
auch noch immer den richtigen Ausgang ansteuern. Wenn man auch noch
die Motorbelastung messen will um evtl. etwas Strom zu sparen, wird
es richtig lustig. Daher lass ich das erst mal weg...
Peter Wagner
Stefan Sczekalla schrieb:
> du decodierst DCC mit Compiliertem Basic - das geht ?
Kommt auf die Taktrate an, es sind ja nur rund 6000 Baud.
--
SchöNe Grüße aus WieN,
Peter Wagner. Spur N, DCC.
Modelleisenbahnclub "Die 160er" - Mitgliedsclub des VOEMEC.
Stefan Sczekalla
> Verwende die hier beschriebene Mehthode, ist gar nicht so kompliziert.
> Leider wollte der Autor seinen Sourcecode nicht weitergeben, so muß ich
> mich halt selbst versuchen.
> Er hat die Vorgangsweise auf seiner Seite super beschrieben.
aber in 2-3 Nachmittagen ist das nicht programmiert - oder ?
Grüße,
Stefan
Kurt Harders
Matthias Kordell wrote:
> Manfred Richter tut geschreibselt haben:
>
> > Falls Du natürlich doch mit uC's etwas machen willst, dann findest
> > Du für den Atmel etwas unter http://bahn-in-haan.de ,
> > http://www.amhamberg.de
>
> Hmm, das sind alles nur Weichendecoder. Gibt es auch sowas für
> Lokdecoder?
Mindestens der erste Link beschreibt eine Dokodierung, die nicht
NMRA-konform ist :-). Es macht meist schon Sinn, die beiden
Signalhälften zu vergleichen und die Zeiten zu überprüfen. Trotzdem
funktioniert der Decoder natürlich und man hat durch die Prüfung nur
eines Halb-Bits mehr Rechenzeit frei.
Grundätzlich kann man aber das beschriebene Verfahren leicht ergänzen:
- Auf Flanke warten, dann Zeit zur nächsten Flanke messen
- Zeit merken und nächstes Halbbit bearbeiten
- Das so lange machen, bis man 22 Halbbits erkannt hat
- Auf ersten langen Impuls warten. Der Startet die Daten.
- Bitlänge merken. Andere Flanke erwarten
- Bitlängen vergleichenund einer 0 oder 1 zuordnen. Daten in ein Byte
schieben
- Nach dem ersten Byte die Restlänge bestimmen (s. NMRA RP)
- restliche Bytes einlesen
- Parity einlesen
- Parity prüfen
Das Ganze lässt man von einer Statemchine abarbeiten. Dann ist es
selbst mit einem Takt von 1ľs machbar.
Gruß, Kurt
--
Kurt Harders
MBTronik - PiN - Präsenz im Netz GITmbH
mailto:ne...@kurt-harders.de
http://www.mbtronik.de
Bernhard Baptist
>
> Mindestens der erste Link beschreibt eine Dokodierung, die nicht
> NMRA-konform ist :-). Es macht meist schon Sinn, die beiden
> Signalhälften zu vergleichen und die Zeiten zu überprüfen. Trotzdem
> funktioniert der Decoder natürlich und man hat durch die Prüfung nur
> eines Halb-Bits mehr Rechenzeit frei.
Nur interessehalber:
Wo siehst du ein Problem bei Verwendung dieser Methode ?
Mal abgesehn davon, das die im zitierten Projekt vorgschlagene
Optokopplerlösung zur filterung von Spikes IMHO unsauber ist.
Das sollte sich wohl in Software reproduzierbarer lösen lassen.
Kurt Harders
Bernhard Baptist wrote:
> Am 23 Jan 2005 07:02:58 GMT schrieb Kurt Harders
> <ne...@kurt-harders.de>:
>
> Wo siehst du ein Problem bei Verwendung dieser Methode ?
Kein Problem, ich habe nur Korinthen gekackt :-). Nach NMRA gibt es
exakte Grenzen, in denen eine 0 und eine 1 liegen. Der Sender soll
55-61µs senden, und beide Teile eines Bits sollen gleich lang sein, der
Empfänger soll alles im Bereich 52-64µs als 1 auswerten. Für die 0 sind
das 95-9900µs für den Sender und 90-12000µs für den Empfänger. Damit
ist das Samplefenster eher eng, in dem man die Entscheidung treffen
kann, nämlich die Mitte von 64-90µs, also 77µs. Wenn man dort eine
Störung erwischt, wird es ungenau.
> Mal abgesehn davon, das die im zitierten Projekt vorgschlagene
> Optokopplerlösung zur filterung von Spikes IMHO unsauber ist. Das
> sollte sich wohl in Software reproduzierbarer lösen lassen.
Spikes in Software zu erkennen ist schwierig, da man alles unterhalb
1µs (so grob) nicht mitbekommt, aber sehr wohl gerade abgetastet haben
kann. Mit meiner Empfangsroutine, die die NMRA-Kriterien prüft, bin ich
selbst mit langsamen Optokopplern noch hingekommen. Zusätzlich zu den
Störungen kommen dann noch unterschiedliche Flankensteilheiten bei z.B.
Lenz und IB. Da man in der Regel nicht im Nulldurchgang, sondern
oberhalb, bei ca. 2V die Schwelle erkennt, wird es um einige µs
ungenauer, weil NMRA 2,5V/µs verlangt im Bereich +/-4V. Das bringt dann
auch noch 1 µs.
Die in S 9.1 gegebenen Werte sollte man schon als Ausgangspunkt nehmen,
sonst könnte z.B. auch ein MM-Signal mal sonderbare Ergebnisse liefern
:-).
Manfred Richter
in Zwischencode, der zur Laufzeit interpretiert werden muss. Daher ist die
Geschwindigkeit nicht das Problem. Allerdings der Platz ;-) , zumindest wenn
man das ganze auf einem preisgünstigen 2313 realisieren will. Bei Mega's
geht das natürlich problemlos.
"Bernhard Baptist" <x...@carinthians.com> schrieb im Newsbeitrag
news:opsk0vuk...@buero.arbeitsgruppe...
Bernhard Baptist
>>
>> Wo siehst du ein Problem bei Verwendung dieser Methode ?
>
> Kein Problem, ich habe nur Korinthen gekackt :-).
Zum Glück, bin ja gerade dabei mir nach der Methode was zu stricken.
>
> Spikes in Software zu erkennen ist schwierig, da man alles unterhalb
> 1µs (so grob) nicht mitbekommt, aber sehr wohl gerade abgetastet haben
Vieleicht stelle ich mir das jetzt zu einfach vor, (zt. läufts ja nur in
"sauberer Umgebung") doch folgender Code sollte doch an einem 4Mhz AVR
Spikes unterhalb weniger uS rausfiltern.
Nach Interrupt (Flanke erkannt) Pegel abtasten und speichern.
nach kurzer Zeit (einige nop's) nochmals abtasten und schauen ob noch der
gleiche Pegel.
Wenn ja -> Bit OK, wenn nein -> so wars ein Spike
Ok, ist sicher auch nicht 100%tig aber einfach und besser als nichts.
On Int0 Pulse_isr
Do
Loop
Pulse_isr:
Bit_read = Pind.2
nop
nop
If Bit_read = Pind.2
Then Timer0 = Detect_time
Disable Int0
Enable Timer0
End If
Return
Man könnte zb. auch mehrmals hintereinander sampeln, den Mittelwert
bilden, dieser darf nur ganzzahlig 1 oder 0 keinen Zwischenwert. Dann
liegt konstantes Signal an.
Thomas Einzel
...
> Damit ist das Samplefenster eher eng, in dem man die
> 77ľs. Wenn man dort eine Störung erwischt, wird es ungenau.
...
> Spikes in Software zu erkennen ist schwierig, da man alles
> abgetastet haben kann.
Hallo Kurt,
kann man von der Rechenzeit her mehrere Samples machen und damit
zumindest einzelne Spikes herausrechenen? Wenn du das mit einer
Interrupt service routine machst, könnte es innerhalb der ISR zeitlich
eng werden - ggf. außerhalb? Wenn man innerhalb des zulässigen
Zeitfensters min.drei Abtastungen macht, diese cached und vergleicht,
sollte die Mehrheit (2 von 3) zu einem besseren Ergebnis führen als
ein einziger Wert. Oder pollst du nur an dem Port?
BTW: ich weiß nicht, ob ein relativ einfacher Tiefpaß helfen könnte,
hat das schon mal jemand probiert? Sehr viel schneller als 10ľs muß
doch das Signal nie sein, wenn ich das recht verstanden habe...
BTW2: wie lang sind eigentlich die spikes, mit denen man rechnen muß?
Thomas
Stefan Sczekalla
"Manfred Richter" <bla...@amhamberg.de> wrote in
news:35i9kkF...@individual.net:
> Bascom übersetzt beim compilieren in Assembler
Ist das Compilat nicht sehr sperrig und "langsam" - eine gute Optimierung
stelle ich mir da schon schwierig vor ?
Wie ist das denn mit der Vorhersagbarkeit der Laufzeit von Basic-Sequenzen
?
Grüße,
Stefan
Jochen Dolze
Bernhard Baptist wrote:
> Servus
> Ich stand vor zwei Wochen vor genau der selben Frage :-)
> Informationen und Projekte gibts im Web ja einige, allerdings leider
> größtenteils ohne Sourcecode.
Ohne Sourcecode nützt es mir nichts. Ich möchte ja kein "Bastelworkshop"
zum Zeitvertreib, sondern auf bestimmte Befehle reagieren können. Dazu
benötige ich aber erstmal ein Grundgerüst, das die Befehle einliest.
> Einige Quellen wurden ja schon genannt.
> Ich wollte aber meinen EIGENEN Decoder, und nicht bloß fertige Projkte
> nachbauen.
Nunja, ein fertiges Projekt nachbauen möchte ich auch nicht,
genausowenig einen eigenen Decoder bauen. Das können andere bestimmt besser.
> So wie von dir treffend erwähnt, begin bei Adam&Eva. ist aber gar nicht
> schwer, auf
> http://www.nmra.org/standards/consist.html#standards-DCC ist alles
> wunderbar documentiert.
"A-ber isch 'abe doch nicht soviel Zeit" ;)
> Bin jederzeit an Erfahrungsaustausch interesiert.
Hast Du über Deine Erfahrungen etwas dokumentiert?
Gruß
Jochen
Armin Muehl
> Zusätzlich zu den
>Störungen kommen dann noch unterschiedliche Flankensteilheiten bei z.B.
>Lenz und IB.
Hast Du Deinen Decoder schon mal mit einem Spax-Booster und langen
duennen Zuleitungen getestet?
Das ist dann der Test, ob ein Decoder resistent gegen versaute Signale
mit Ueberschwingern ist...
Einen Lenz-Decoder kann man damit in die Umlaufbahn schiessen :-)
Armin
Armin Muehl
http://www.museumsstellwerk.de (Museumsstellwerk Rheine e.V.)
http://www.muehlenroda.de (Muehl privat)
http://de.geocities.com/anschlussbahn (Modellbahnbilder)
Bernhard Baptist
<der_...@dolze.de>:
> Hallo Bernhard,
>
> Nunja, ein fertiges Projekt nachbauen möchte ich auch nicht,
> genausowenig einen eigenen Decoder bauen. Das können andere bestimmt
> besser.
Och, wennst mit uC umgehen kannst, und das mußt du ja offensichtlich
können wenn du dann ein Program selbst erweitern willst ises gar nicht
schwer. Eigentlich sogar recht leicht.
Persönlich habe ich wohl einiges an Programiererfahrung, aber alles auf
PC's oder Sun's.
Mit uC hatte ich noch nie zu tun.
Für programieren, einlesen in den DCC Standard,lernen von AVR Grundlagen
hab ich nun ca. 50 Stunden aufgewendet.
Vor ~10 Minuten hat nun die erste Weiche per Intellibox gesteuert
geschalten (naja simuliert mit einer LED).
Nun muß noch eine Funktion für Adresse u. Schaltzeiteinstellung rein, dann
ist fertig.
Klar Austesten und optimieren ist auch noch notwendig, also nochmals 50
Stunden und dann sollte es passen.
Bis jetzt sinds übrigens nur ca. 1.5kByte Code, alos wirklich nict
tragisch.
> "A-ber isch 'abe doch nicht soviel Zeit" ;)
Tja arbeiten bis Sonnenuntergang, programieren bis zum Sonnenaufgang, dann
geht das schon.
> Hast Du über Deine Erfahrungen etwas dokumentiert?
zzt. noch nicht, ist ja gerade erst alles im Entstehen.
Wenn ich aber fertig bin, so kannst den Code & Schaltplan natürlich gerne
haben. Kein Problem.
Wird aber noch etwas dauern, da ich ab morgen leider für mindesten 2
Wochen ins Krankenhaus muß. :-(
Melde dich dann mal, oder schau so in einem Monat mal auf meiner Homepage
vorbei.
Fritz Ganter
> Ich will erst mal mit einem ATMega16 anfangen zu experimentieren,
> der sollte ausreichend Platz bieten. Gibt es irgendwo auch Projekte
> für gcc?
http://www.nongnu.org/avr-libc/
Installation findest da:
http://www.nongnu.org/avr-libc/user-manual/install_tools.html
Ich wollte auch einen (Funktions-)Decoder bauen und programmieren, aber es
kam immer was dazwischen, kommt schon noch...
--
Fritz "der mit dem Linux tanzt" Ganter http://traindrive.gpsdrive.cc
Key fingerprint = 555A DDBB 3985 16FF CD41 2031 C485 1783 BF34 728F
Kurt Harders
Bernhard Baptist wrote:
> Vieleicht stelle ich mir das jetzt zu einfach vor, (zt. läufts ja nur
> in "sauberer Umgebung") doch folgender Code sollte doch an einem
> 4Mhz AVR Spikes unterhalb weniger uS rausfiltern. Nach Interrupt
> (Flanke erkannt) Pegel abtasten und speichern. nach kurzer Zeit
> (einige nop's) nochmals abtasten und schauen ob noch der gleiche
> Pegel. Wenn ja -> Bit OK, wenn nein -> so wars ein Spike Ok, ist
> sicher auch nicht 100%tig aber einfach und besser als nichts.
Du erwischst die Flanke und dann beim Sample noch einen Spike :-).
Grundätzlich muss man mit so etwas leben. Ich habe in meiner Erkennung
keine Spikes berücksichtigt, sondern arbeite nur mit Flanken. Wenn
jetzt ein Spike auftritt, wird der Impuls als "falsche Länge" erkannt
und die Präambelsuche beginnt von vorn.
> Man könnte zb. auch mehrmals hintereinander sampeln, den Mittelwert
> bilden, dieser darf nur ganzzahlig 1 oder 0 keinen Zwischenwert. Dann
> liegt konstantes Signal an.
Das ist doch aber viel umständlicher als eine saubere Impulserkennung.
Mit 1µ/Befehl ist man auch schenll genug das zu tun. Allerdings spreche
ich hier von Assembler.
Kurt Harders
Thomas Einzel wrote:
> kann man von der Rechenzeit her mehrere Samples machen und damit
> zumindest einzelne Spikes herausrechenen? Wenn du das mit einer
> Interrupt service routine machst, könnte es innerhalb der ISR
> zeitlich eng werden - ggf. außerhalb? Wenn man innerhalb des
> zulässigen Zeitfensters min.drei Abtastungen macht, diese cached und
> vergleicht, sollte die Mehrheit (2 von 3) zu einem besseren Ergebnis
> führen als ein einziger Wert. Oder pollst du nur an dem Port?
s. Meine Antwort an Bernhard. Das ist alles viel komplizierter als eine
saubere Impulsanalyse.
> BTW: ich weiß nicht, ob ein relativ einfacher Tiefpaß helfen könnte,
> hat das schon mal jemand probiert? Sehr viel schneller als 10µs muß
> doch das Signal nie sein, wenn ich das recht verstanden habe...
Dann hast Du endgültig keine sauberes Signal mehr. Und so ein Tiefpass
kostet Geld: Bauteile, Platinenfläche und Löcher :-).
> BTW2: wie lang sind eigentlich die spikes, mit denen man rechnen muß?
Vergiss sie. Baue eine NMRA-konforma Impulsprüfung ein, wobei man die
Regel für 2xgleich lang evtl. weg lassen kann, und gut ist.
Kurt Harders
Armin Muehl wrote:
> Hast Du Deinen Decoder schon mal mit einem Spax-Booster und langen
> duennen Zuleitungen getestet?
> Das ist dann der Test, ob ein Decoder resistent gegen versaute Signale
> mit Ueberschwingern ist...
Nein, hatte ich noch keine Gelegenheit zu. Aber MoBaSchaZ erzeugt auch
(noch normgerechte) Schwinger im Nulldurchgang. Wenn Du das testen
willst, stelle ich gerne ein Muster bereit :-).
Armin Muehl
>> Hast Du Deinen Decoder schon mal mit einem Spax-Booster und langen
>> duennen Zuleitungen getestet?
>> Das ist dann der Test, ob ein Decoder resistent gegen versaute Signale
>> mit Ueberschwingern ist...
>
>Nein, hatte ich noch keine Gelegenheit zu. Aber MoBaSchaZ erzeugt auch
>(noch normgerechte) Schwinger im Nulldurchgang. Wenn Du das testen
>willst, stelle ich gerne ein Muster bereit :-).
Deine Steuerung erzeugt aber keine Signale fuer Lokdecoder. Bei den
Lenz-Lokdecodern haben wir damit seinerzeit unsere Erlebnisse
gehabt...
Thomas Einzel
...
>> kann man von der Rechenzeit her mehrere Samples machen und damit
>> zumindest einzelne Spikes herausrechenen?
> s. Meine Antwort an Bernhard. Das ist alles viel komplizierter als
> eine saubere Impulsanalyse.
Hallo Kurt,
Hm naja, ich hatte als ersten Gedankenblitz diese sehr asynchronen
Mehrfachsymples,
Berhard dache wohl mehr an Flankengetriggerte Mehrfachsamples. Leider
hast du nicht erwähnt, wie du es besser realisierst. Ich habe jetzt
mal kurz länger darüber nachgedacht und ziehe jetzt eher in Erwägung,
dass eine starr getaktete Abtastung (im 1. Step würde ich es mit der
doppelten Abtastrate der max auftretenden DCC Frequenz machen) und
eine daraus folgende Anneliese ;-) wahrscheinlich schon die meisten
Fehler herausrechnen kann (einfache Logik, ggf. Statistik). Ohne
Kenntnisse von Steilheit, Länge und ggf. Amplitude aber vor allem
Häufigkeit der Störungen ist das jedoch Kaffeesatzleserei meinserseits
;-)) Wenn es überhaupt wirkliches Spikeproblem gibt...
...
>> BTW: ich weiß nicht, ob ein relativ einfacher Tiefpaß helfen
>> könnte, hat das schon mal jemand probiert? Sehr viel schneller
>> als 10µs muß doch das Signal nie sein, wenn ich das recht
>> verstanden habe...
>
> Dann hast Du endgültig keine sauberes Signal mehr. Und so ein
> Tiefpass kostet Geld: Bauteile, Platinenfläche und Löcher :-).
Wenn mna dmait das Signal von Spikes befreien könnte, wäre das Signal
schon sauberer, verschliffene Flanken sind in so fern egal, wenn sie
die Lesbarkeit des Signals nicht negativ beeingflussen. 2 R und ein C,
0,5cm² und 0 Löcher - man muß nicht alles digital realsieren. Aber
der Tiefpaß war ja mehr eine Zwischenfrage, dazu stehe ich zu wenig in
eurer Frage drin.
...
> Vergiss sie. Baue eine NMRA-konforma Impulsprüfung ein
Hättest du da vielleicht so einen klitzekleinen, nützlichen link für
mich?
Danke.
Thomas
Kurt Harders
Thomas Einzel wrote:
> Hm naja, ich hatte als ersten Gedankenblitz diese sehr asynchronen
> Mehrfachsymples,
> Berhard dache wohl mehr an Flankengetriggerte Mehrfachsamples. Leider
> hast du nicht erwähnt, wie du es besser realisierst. Ich habe jetzt
> mal kurz länger darüber nachgedacht und ziehe jetzt eher in Erwägung,
> dass eine starr getaktete Abtastung (im 1. Step würde ich es mit der
> doppelten Abtastrate der max auftretenden DCC Frequenz machen) und
> eine daraus folgende Anneliese ;-) wahrscheinlich schon die meisten
> Fehler herausrechnen kann (einfache Logik, ggf. Statistik). Ohne
> Kenntnisse von Steilheit, Länge und ggf. Amplitude aber vor allem
> Häufigkeit der Störungen ist das jedoch Kaffeesatzleserei
> meinserseits ;-)) Wenn es überhaupt wirkliches Spikeproblem gibt...
Ich habe ja meine Meinung (und also meine Realisierung) beschrieben:
Flankentriggerung und dann ordentlich annelisieren.
> Wenn mna dmait das Signal von Spikes befreien könnte, wäre das Signal
> schon sauberer, verschliffene Flanken sind in so fern egal, wenn sie
> die Lesbarkeit des Signals nicht negativ beeingflussen. 2 R und ein
> C, 0,5cm² und 0 Löcher - man muß nicht alles digital realsieren.
Das sind bedrahtet 6 Löcher = ca. 0,10 EUR.
> Hättest du da vielleicht so einen klitzekleinen, nützlichen link für
> mich?
http://www.nmra.org/standards/consist.html#standards-DCC
Sowas?
Reinhard Mueller
Kurt Harders schrieb:
> Bernhard Baptist wrote:
>>Am 23 Jan 2005 07:02:58 GMT schrieb Kurt Harders
>>> Mindestens der erste Link beschreibt eine Dokodierung, die
>>> nicht NMRA-konform ist :-)
Hm, wo steht, dass ein Decoder beide Bithälften ansehen muss?
Das es besser ist, steht ausser Frage.
>> Wo siehst du ein Problem bei Verwendung dieser Methode ?
>
> Kein Problem, ich habe nur Korinthen gekackt :-). Nach NMRA
> gibt es exakte Grenzen, in denen eine 0 und eine 1 liegen. Der
> Sender soll 55-61µs senden, und beide Teile eines Bits sollen
> gleich lang sein, der Empfänger soll alles im Bereich 52-64µs
> als 1 auswerten. Für die 0 sind das 95-9900µs für den Sender
> und 90-12000µs für den Empfänger. Damit ist das Samplefenster
> eher eng, in dem man die Entscheidung treffen kann, nämlich
> die Mitte von 64-90µs, also 77µs.
Viele gehen über eine einfache Abtastung alle 22 us. In eine
Hälfte einer "1" (<= 64 us) passen maximal 3 Sample mit dem
gleichen Wert (66us > 64us), in die Hälfte einer "0" (>= 90us)
minimal 4 Sample. (88 < 90). Bei einem Spike bekommt man eben
ungültige Bits (nur ein gleiches Sample oder verschiedene
Informationen von den beiden Hälften) und verliert das Paket.
Wenn man die Bits als Ganzes sieht, gehen sogar Abtastungen mit
44 us, aber dann wird es sehr haarig. ;-)
Gruß,
Reinhard
Martin Schoenbeck
Reinhard Mueller schrieb:
> Hm, wo steht, dass ein Decoder beide Bithälften ansehen muss?
> Das es besser ist, steht ausser Frage.
Letzteres aber nur dann, wenn er die zusätzliche Information nutzt, um den
Befehl doch noch zu verstehen, nicht um ihn zu ignorieren.
Gruß Martin
--
Bitte nicht an der E-Mail-Adresse fummeln, die paßt so.
-------------------------------------------------------
Softwarepatente? Nein, danke. Hier eintragen:
http://petition.eurolinux.org/index_html
Stefan Sczekalla
@individual.net:
> BTW: ich weiß nicht, ob ein relativ einfacher Tiefpaß helfen könnte,
> hat das schon mal jemand probiert? Sehr viel schneller als 10µs muß
> doch das Signal nie sein, wenn ich das recht verstanden habe...
>
> BTW2: wie lang sind eigentlich die spikes, mit denen man rechnen muß?
>
> Thomas
... ich möchte noch zu Bedenken geben, ob der Booster als "Signalquelle"
nicht sowieso so Niederohmig ist, dass Spikes schon mächtig Leistung haben
muessten um das Signal zu verfälschen.
Grüße,
Stefan
Stefan Sczekalla
"Kurt Harders" <ne...@kurt-harders.de> wrote in news:35jjomF4l0s2iU2
@individual.net:
>> BTW2: wie lang sind eigentlich die spikes, mit denen man rechnen muß?
>
> Vergiss sie. Baue eine NMRA-konforma Impulsprüfung ein, wobei man die
> Regel für 2xgleich lang evtl. weg lassen kann, und gut ist.
ich war jetz schon "zweimal" auf der DCC Seite der NRMA, - den Teil "NRMA-
Konforme pulsprüfung hab ich aber nciht gefunden.
Du meinst damit aber nicht, die "Validierung" der empfangenen Daten ?
( so mit XOR etc ... )
Grüße,
Stefan
Thomas Einzel
...
> Ich habe ja meine Meinung (und also meine Realisierung)
> beschrieben: Flankentriggerung und dann ordentlich annelisieren.
HalloKurt,
rein asynchron? Ich weiß ja nicht ob es wirklich ein Störungsproblem
gibt, wenn nicht, ist das Gespräch rein von akademischem Interesse,
ist das Spikeproblem jedoch massiv, hauen dir die Flanken der Spikes
deine Analyse durcheinander - die vermutlich (Assembler?)
hauptsächlich aua logik bestehen wird (?).
>> 2 R und ein C, 0,5cm² und 0 Löcher - man muß
>> nicht alles digital realsieren.
>
> Das sind bedrahtet 6 Löcher = ca. 0,10 EUR.
BTW: Warum willst du für SMDs Löcher bohren? (ich schrieb doch 0
Löcher).
>> Hättest du da vielleicht so einen klitzekleinen, nützlichen link
>> für mich?
>
> http://www.nmra.org/standards/consist.html#standards-DCC
>
> Sowas?
Ähm - danke, eien Hinweis auf die NMRA konforme Dekodierung hätte mir
gelangt. Es beginnt sich je gerade einzuschneien, da hätte ich
Lesestoff für viele, viele Wochen =:-) Oder für den nächsten Winter...
gütiger...
Thomas
Kurt Harders
Martin Schoenbeck wrote:
> Hallo Reinhard,
>
> Reinhard Mueller schrieb:
>
> > Hm, wo steht, dass ein Decoder beide Bithälften ansehen muss?
> > Das es besser ist, steht ausser Frage.
>
> Letzteres aber nur dann, wenn er die zusätzliche Information nutzt,
> um den Befehl doch noch zu verstehen, nicht um ihn zu ignorieren.
Ihr irrt :-). NMRA S9.1 sagt in Abschnitt A ganz eindeutig, dass beim
Senden 3µs Differenz erlaubt sind, und der Decoder eine Differenz von
6µs als OK akzeptieren muss. Wenn bei NMRA must steht, heisst das, dass
nur diese Werte erlaubt sind.
Man kann darauf verzichten, aber dann ist man halt ausserhalb des in
der Norm festgelegten Verhaltens.
Kurt Harders
Stefan Sczekalla wrote:
> ich war jetz schon "zweimal" auf der DCC Seite der NRMA, - den Teil
> "NRMA- Konforme pulsprüfung hab ich aber nciht gefunden.
Standards&RPs -> DCC-Standards -> S9.1 Abschnitt A
Kurt Harders
Thomas Einzel wrote:
> rein asynchron? Ich weiß ja nicht ob es wirklich ein Störungsproblem
> gibt, wenn nicht, ist das Gespräch rein von akademischem Interesse,
> ist das Spikeproblem jedoch massiv, hauen dir die Flanken der Spikes
> deine Analyse durcheinander - die vermutlich (Assembler?)
> hauptsächlich aua logik bestehen wird (?).
Es ist offenbar eher akademisch :-), denn meine asynchrone Analyse
funktioniert ja.
> > Das sind bedrahtet 6 Löcher = ca. 0,10 EUR.
>
> BTW: Warum willst du für SMDs Löcher bohren? (ich schrieb doch 0
> Löcher).
Weil ich Bausätze noch immer nicht als SMD verkaufe :-).
Martin Schoenbeck
Kurt Harders schrieb:
> Ihr irrt :-). NMRA S9.1 sagt in Abschnitt A ganz eindeutig, dass beim
> Senden 3µs Differenz erlaubt sind, und der Decoder eine Differenz von
> 6µs als OK akzeptieren muss. Wenn bei NMRA must steht, heisst das, dass
> nur diese Werte erlaubt sind.
Ist das so? Ich habe das nirgendwo finden können und würde ein 'must'
erstmal als zu erfüllende Mindestbedingung ansehen. Was der Dekoder mit
Werten macht, die da rausfallen, und weder in das Raster für die 0 noch die
1 fallen, wäre danach erstmal seine Sache. Solange hinterher die Prüfsumme
paßt, sollte das dann für eine erfolgreiche Rekonstruktion sprechen.
> Man kann darauf verzichten, aber dann ist man halt ausserhalb des in
> der Norm festgelegten Verhaltens.
Je nachdem wie Du 'darauf verzichten' interpretierst. Wenn das natürlich
dazu führt, daß Du ein Bit nicht erkennst, obwohl es innerhalb der obigen
Werte liegt, dann hast Du recht.
Reinhard Mueller
das wird jetzt etwas länger, aber da von dir immer nur ein Verweis
auf Abschnitt A von S-9.1 kommt, sehen wir uns das mal genauer an.
Kurt Harders schrieb:
> Hallo Martin, hallo Reinhard,
> Martin Schoenbeck wrote:
>> Reinhard Mueller schrieb:
>>> Hm, wo steht, dass ein Decoder beide Bithälften ansehen muss?
>>> Das es besser ist, steht ausser Frage.
>>
>> Letzteres aber nur dann, wenn er die zusätzliche Information nutzt,
>> um den Befehl doch noch zu verstehen, nicht um ihn zu ignorieren.
>
> Ihr irrt :-). NMRA S9.1 sagt in Abschnitt A ganz eindeutig, dass
> beim Senden 3µs Differenz erlaubt sind, und der Decoder eine Differenz
> von 6µs als OK akzeptieren muss.
Soweit alles klar.
> Wenn bei NMRA must steht, heisst das, dass nur diese Werte erlaubt sind.
Wie kommst Du darauf? Null Toleranz für den Decoder?
Also, der Decoder muss alles bis zu einer Differenz von 6 us als
gültig akzeptieren:
"Digital Decoders must accept one bits whose positive and
negative components differ by as much as 6 microseconds."
Aber er muss nicht alles was darüber ist verwerfen. Denn sonst gäbe
es für den Decoder null Toleranz: 6 us ist OK, aber 6,01 us müssen
verworfen werden? Das schafft selbst der beste Decoder nicht.
Ansonsten müsste der Decoder ja auch prüfen, dass eine "1"-Hälfte
weder unter 52 us noch über 64 us lang ist und eine "0"-Hälfte
nicht unter 90 us lang ist.
"A Digital Decoder must accept bits whose first and last parts
have a duration of between 52 and 64 microseconds, as a valid
bit with the value of "1"."
[snip]
"A Digital Decoder must accept bits whose first or last parts
have a duration of between 90 and 10000 microseconds as a valid
bit with the value of "0"."
In allen Zitaten steht ganz deutlich "must accept". In dem
gesammten Abschnitt steht aber nicht, was ein Decoder verwerfen
muss. Ja, das ist schräg, aber so sind die Normen geschrieben.
Und Du schriebst ja selbst am 23.01.2005 um 17:50
"Damit ist das Samplefenster eher eng, in dem man die
Entscheidung treffen kann, nämlich die Mitte von 64-90µs,
also 77µs."
Also prüfst auch Du nicht das korrekte Timing.
Genauso mit den Bithälften. Wenn beide Bithälften im Bereich
52 bis 64 us liegen, muss eine "1" erkannt werden, aber wo steht
bitte, dass der Decoder beide Hälften prüfen muss?
Bei dem Entwurf der Signalform war ja die Anforderung, von der
Polung unabhängig zu sein. Märklin brauchte ja ein System für die
2-Leiter-Gleise von Spur 1. Und das Motorola-Protokol konnte man
damals nicht unabhängig von der Polung auswerten, was mit heutigen
PICs & Co. kein Problem ist. Und damals hat man nur eine Bithälfte
betrachtet. Geht ja. Ist ja egal, ob man immer die erste oder immer
die zweite Hälfte betrachtet. Allerdings verschenkt man damit
Erkennungsrate.
Man hat bewusst die Anforderungen nach Möglichkeit auf die
Signalerzeugung geschoben, damit der unter Platznot leidende Teil
im Fahrzeug einfach wird.
Gruß,
Reinhard
Kurt Harders
Reinhard Mueller wrote:
> Wie kommst Du darauf? Null Toleranz für den Decoder?
Nein, die Toleranzen sind ja wohl definiert. Vielleicht habe ich mich
aber auch zu sehr durch dir RFCs im Internet verleiten lassen, das must
so zu interpretieren. Ich halte es aber für sinnvoll.
> Also, der Decoder muss alles bis zu einer Differenz von 6 us als
> gültig akzeptieren:
> "Digital Decoders must accept one bits whose positive and
> negative components differ by as much as 6 microseconds."
> Aber er muss nicht alles was darüber ist verwerfen. Denn sonst gäbe
> es für den Decoder null Toleranz: 6 us ist OK, aber 6,01 us müssen
> verworfen werden? Das schafft selbst der beste Decoder nicht.
Die 6µs dürfen nicht unterschritten werden. Mehr steht da nicht.
> Ansonsten müsste der Decoder ja auch prüfen, dass eine "1"-Hälfte
> weder unter 52 us noch über 64 us lang ist und eine "0"-Hälfte
> nicht unter 90 us lang ist.
Genau das muss er auch tun.
> "A Digital Decoder must accept bits whose first and last parts
> have a duration of between 52 and 64 microseconds, as a valid
> bit with the value of "1"."
> [snip]
> "A Digital Decoder must accept bits whose first or last parts
> have a duration of between 90 and 10000 microseconds as a valid
> bit with the value of "0"."
>
> In allen Zitaten steht ganz deutlich "must accept". In dem
> gesammten Abschnitt steht aber nicht, was ein Decoder verwerfen
> muss. Ja, das ist schräg, aber so sind die Normen geschrieben.
Nun ja, wie schon gesagt, ich interpretiere Normen immer so, dass nur
die erwähnten Eigenschaften erlaubt sind.
> Und Du schriebst ja selbst am 23.01.2005 um 17:50
> "Damit ist das Samplefenster eher eng, in dem man die
> Entscheidung treffen kann, nämlich die Mitte von 64-90µs,
> also 77µs."
> Also prüfst auch Du nicht das korrekte Timing.
Genau so prüfe ich nicht :-). Das war nur ein Hinweis auf den damaligen
Auslöser dieser (akademischen) Debatte. Ich prüfe sehr wohl
(weitgehend) die Längen. Eine Einschränkung entsteht durch Laufzeiten
in den Optokopplern und die Flankenerkennung.
> Genauso mit den Bithälften. Wenn beide Bithälften im Bereich
> 52 bis 64 us liegen, muss eine "1" erkannt werden, aber wo steht
> bitte, dass der Decoder beide Hälften prüfen muss?
Ich würde die besagten 6µs so interpretieren. Wenn ich allerdings daran
denke, dass asymetrische Nullen erlaubt sind...
Mein eigentlicher Beitrag sollte auch nur sein: keine komplizierte
Spikeerkennung, sondern das Signal mit den gegebenen Eigenschaften
auswerten.
Reinhard Mueller
Kurt Harders schrieb:
> Reinhard Mueller wrote:
>>Also, der Decoder muss alles bis zu einer Differenz von 6 us als
>>gültig akzeptieren:
>> "Digital Decoders must accept one bits whose positive and
>> negative components differ by as much as 6 microseconds."
>>Aber er muss nicht alles was darüber ist verwerfen. Denn sonst gäbe
>>es für den Decoder null Toleranz: 6 us ist OK, aber 6,01 us müssen
>>verworfen werden? Das schafft selbst der beste Decoder nicht.
>
> Die 6µs dürfen nicht unterschritten werden. Mehr steht da nicht.
Die 6 us dürfen vom Signal nicht _über_schritten werden, damit
der Decoder es als gültig erkennen muss. Ab wieviel us Differenz
und welcher Toleranz lehnt dein Decoder ein Bit als ungültig ab?
>>Ansonsten müsste der Decoder ja auch prüfen, dass eine "1"-Hälfte
>>weder unter 52 us noch über 64 us lang ist und eine "0"-Hälfte
>>nicht unter 90 us lang ist.
>
> Genau das muss er auch tun.
Wirklich? Und, macht das dein Decoder?
>> In allen Zitaten steht ganz deutlich "must accept". In dem
>> gesammten Abschnitt steht aber nicht, was ein Decoder verwerfen
>> muss. Ja, das ist schräg, aber so sind die Normen geschrieben.
>
>
> Nun ja, wie schon gesagt, ich interpretiere Normen immer so,
> dass nur die erwähnten Eigenschaften erlaubt sind.
Dann gehst Du unnötig hart an die Grenzen. Ein Bit mit 64 us
langen Hälften musst Du als "1" erkennen. Ab wann willst Du
es als ungültig erkennen?
> Ich prüfe sehr wohl (weitgehend) die Längen. Eine
> Einschränkung entsteht durch Laufzeiten in den
> Optokopplern und die Flankenerkennung.
Und damit wirst Du nicht hart an die 64 us ran gehen können.
Gruß
Reinhard
Stefan Sczekalla-Waldschmidt
> Ich prüfe sehr wohl
> (weitgehend) die Längen. Eine Einschränkung entsteht durch Laufzeiten
> in den Optokopplern und die Flankenerkennung.
"interrupt on change" + wo der Timer nach Flanken-irq steht ?
Grüße,
Stefan