DMX-Empfang klappt nicht

Die Hardware mit dem 75176 sieht soweit ganz gut aus, aber:

niemals einen 3-pol Steckverbinder verwenden. Die DMX-Specs sehen eine 
5-pol vor.

Bist du sicher, dass der Sender richtig arbeitet?

Hast du einen Quarz eingebaut und die Baudrate richtig berechnet?

Greifst du aus dem Datenstrom auch das richtige Byte raus?

MW

@Michael: Das mit dem 5-poligem Stecker ist so nicht ganz richtig. Man 
kann wunderbar auch den 3-poligen verwenden. Nur halt nicht die 
Standard-Mikrofon-Kabel nehmen, sondern richtige DMX-Kabel. Das mit dem 
5-poligen hat nur zwei zusätzliche Leitungen, für zusätzliche 
Funktionen. Diese sind allerdings weder standardisiert noch werden sie 
von allen Geräten unterstützt. 3-polig reicht für eine 
Standard-DMX-Kommunikation also vollkommen aus.

Was mich aber mal interessieren würde... von wo sendest du eigentlich? 
und was sendest du? Vielleicht ist ja der Empfänger in Ordnung nur der 
Sender nicht?

Gruß
PeggySue.

@Mixer: Hast du schonmal ein Oszi drangeklemmt?

@ PeggySue,

such hier im Forum mal nach DMX. Irgendwo habe ich die Specs mal 
reingestellt. Und das mit dem 5-pol Steckverbinder wurde damals von der 
USITT* vorgeschrieben. Nur weil solche Flachköppe wie z. B. Martin ihre 
Geräte mit 3-pol Verbindern ausstatten, macht die Sache nicht besser.

Wenn due das Dokument nicht findest, mach 'ne Meldung. Dann lade ich es 
noch mal hoch.


MW

*United State Institude for Theater Technology

PeggySue wrote:
> @Michael: Das mit dem 5-poligem Stecker ist so nicht ganz richtig. Man
> kann wunderbar auch den 3-poligen verwenden.
Jubb, das spart vorallem im semi-professionellen Bereich reichlich an 
Adapterkabeln von 3 auf 5 und umgekehrt.

> Nur halt nicht die > Standard-Mikrofon-Kabel nehmen, sondern richtige DMX-Kabel.
Bei semi-professionell eigentlich auch kein Thema, ich nehm seit Jahren 
stinknormales Mikrofonkabel. Zwei, dreihundert Meter sind da kein 
Problem. Dafür isses ja RS485.

> Das mit dem 5-poligen hat nur zwei zusätzliche Leitungen, für zusätzliche
> Funktionen. Diese sind allerdings weder standardisiert noch werden sie
> von allen Geräten unterstützt.
Geenau..also d.h., die Leitungen (Talkback) sind sehr wohl 
standardisiert, nur das, was drüber gesendet wird, halt nicht ;-)

> 3-polig reicht für eine
> Standard-DMX-Kommunikation also vollkommen aus.
JJ.

@Mixer S. (mixer)


>niemals einen 3-pol Steckverbinder verwenden. Die DMX-Specs sehen eine
>5-pol vor.



Sender sind fast immer 5Polig
Endgerät 3P.
hat den Vorteil das du XLR-Kabel auch benutzen kannst.
Der 5P Standart wird nach meinen wissen noch nicht benutzt.

http://www.discotechnik.com/proshop/product_info.php?info=p3542_ADJ-ACCU-SPOT-575-movinghead.html

http://www.discotechnik.com/proshop/product_info.php?info=p3049_EUROLITE-TS-155-DMX-Scan--mit-rotierenden-Gobos.html

Aber bitte nich so billige Links...
http://www.soundlight.de/techtips/dmx512/dmx512.htm

@Mixer: Was heißt bei dir eigentlich nun genau, dass er bloß "0" 
empfängt. Vor der Auswertung, oder danach in der Software?

Wenn du ihm mal "per Hand" eine "1" gibst, erkennt er denn wenigstens 
den 0-Durchgang erstmal korrekt? Also den Start einer neuen Sequenz?

Evtl. in dem du mal dein Programm postest.

MW

@Sven Pauli (haku)

Bedeutet: Teure Endgeräte  billige 3P (damit er nicht 5P anfängt)


...aber hier geht es um den Fehler

@Mixer: Also der "Protokoll-Rahmen" stimmt soweit? Nur im Byte steht 
halt jeweils ne "0"? Versteh ich das jetzt richtig?

Für die Blitzgeschwindigkeit der LED wertest du aber nur einen Kanal 
aus, oder?

Kannst du Debuggen? Denn: "Auf jeden Fall blitzt die LED gar nicht, was 
heißen muss, dass im Register fstat eine 0 ist." Mag zwar richtig sein, 
jedoch kannst du daraus ja gar nicht schließen woran es liegt, dass dort 
0 steht. Wäre schon interessant, ob am Eingang das richtige Ankommt und 
an welcher Stelle dann letztendlich der Wert verloren geht.

Könntest statz LED-togglen ja auch vorerst versuchen bei einem Wert 
größer 0 einfach die LED zu aktivieren. Vielleicht stimmt ja auch bei 
deinem "Blick-Mechanismus" irgendwas nicht.

Mixer S. wrote:
> Könnt ich, aber denk nicht dass hier der Fehler ist.

Passt zwar nich ganz, aber ich komm eben von der Führerscheinprüfung, da 
fällts mir halt ein:
Schüler denkt - Gott lenkt, Schüler dachte - Gott lachte!

Nich denken, sondern prüfen!

Vorweg, ich bin nicht der ASM-Freak, aber deine Baudratenberechnung 
verstehe ich nicht. Du teilst 16000 durch 8000. Ergebnis sollte 2 sein. 
Dann saubtrahierst du noch eine 1, bleibt also 1 übrig.
Bei 16MHz muss aber eine 3 in das Baudratenregister.

MW

Moin,

Die Formel für die Baudratenberechnung lautet:
(F_OSC/4000)-1

Wenn Du sie nicht verändert hättest, käme auch brav die 3 raus ;-)

Ansonsten brauchst Du nicht die DIPs von Hand auskommentieren, da ich 
hierfür bereits ein Compiler-Flag vorgesehen habe.

Wird das ein Interface für analoge Strobes?

Viele Grüße,
Hendrik

Bei Problemen mit den Kanälen:

Setz mal am Besten direkt die Startadresse auf 1 (ich vermute hier noch 
einen Denkfehler):

ldi XL, 1
clr XH

Ansonsten scheint der Code zwar etwas ungewöhnlich aber korrekt zu sein. 
(Ich würde die Rate über eine Lookup-Table direkt für den 16bit-Timer 
generieren...)

Viele Grüße,
Hendrik

Moin,

ähm - das sind Grundlagen...
Schau Dir noch mal kurz das ASM-Tut von hier durch. Dort waren glaube 
ich auch Tabellen im Flash beschrieben.

Da kannst ja mal die Sourcen von meinem Strobo-Mod anschauen:
www.hoelscher-hi.de/hendrik/light/pimpstrobe.htm

Viel Erfolg,
Hendrik

Hi,

ich habe ebenfalls das gleiche problem!!

Im Anhang mal ein Ausschnitt aus dem Code!

Ich habe einen externen Quarz mit 8MHz
folgende fuses sind gesetzt CKSEL = 1111 und SUT = 01
Stimmt das alles soweit. Ich hab im Frame_Error mal den ausgang gesetzt 
jedoch kommt das Programm anscheindend gar nicht soweit!!!

Gruß
Joachim

weiß keiner eine lösung?????

@Joachim:
Natürlich kommst Du nicht soweit.

Simulier die ISR doch einfach, dann merkst Du, dass eine der ersten 
Zeilen fehlt und im Handling der Bytes fehlt auch was... (Wahrscheinlich 
hakelt es noch an mehr stellen - aber ich habe jetzt gerade keine Lust 
deinen Job zu machen ;-)

Abgesehen davon existiert seit Monaten eine neuere Version als Lib, die 
einfach eingebunden werden kann. Da dürften solche Fehler nicht mehr 
vorkommen...

Die Lib werkelt mittlerweile in ein paar Tausend Geräten - einige von 
Euch sind einfach etwas nachlässig beim Abtippen oder ändern etwas ohne 
die Folgen wirklich zu verstehen. (Insofern habt Ihr wirklich das 
gleiche Problem.)

Hendrik

Falls es hilft:

Der aktuelle Link lautet
http://www.hoelscher-hi.de/hendrik/light/ressources.htm

VG,
Hendrik

Danke für deine glorreiche Hilfe. Ohne dich wäre ich jetzt nicht weiter 
gekommen!!!

Wenn man dabei etwas lernen möchte, so wie ich, dann ist es auf jeden 
Fall sinnvoll sich fertige Programme zu laden. Denn wenn man die 
Programme selber schreibt, versteht man den Hintergedanken nicht. Ich 
weiß nicht wie du studierst. Wahrscheinlich auch alles nur die Lösung 
abschreiben und sagen ja ich kann es!!! SUPI!!!

Das ist genau mein Problem jetzt. und überdings deine lösung hab ich 
auch schon ettliche zeit und ich habe es mit der von www.mit... 
verglichen.

Trotzdem danke für deine Hilfe. Foren gibt es ja nicht um Fragen zu 
stellen, sondern seine eigene Meinung zu sagen und dass ich auf dies und 
das kein bock hab.

ähh - bitte?

Ich bin mir nicht ganz sicher, ob ich Dich beleidigt habe, indem ich 
schrieb, dass ich keine Zeit habe, für Dich den Code nach (weiteren) 
versteckten Fehlern zu durchsuchen...

Falls es keine Ironie war:

Ich studiere Maschinenbau an einer TU, Vertiefungsrichtung Konstruktion 
und Automatisierung und bin soweit scheinfrei.

Meine Arbeitsweise bei privatem Gebastel:
Ich suche, ob jemand schon etwas Fertiges hat. So muss ich nicht den 
Kreis neu erfinden. Ist eine Änderung nötig, bau ich die Vorlage nach, 
mache mir die betroffenden Abhängigkeiten und Funktionsweisen klar und 
schreibe dann schrittweise um. Durch Versionierung und zwischenzeitliche 
Simulationen / Tests versuche ich permanent die Funktionalität 
beizubehalten. (Nicht, dass ich drauflos werkel und es tut am Ende 
einfach nicht mehr...)

meine Arbeitsweise für richtige Aufgaben:
Ich suche nach Vorlagen und versuche sie mir herzuleiten, so dass ich 
möglichst nicht mit Black Boxes arbeite. Wo ich Neuland betrete, gehe 
ich halt von den Grundlagen aus und versuche möglichst viel in kleinen 
Schritten zu verifizieren.

Das ist ansich trivial und dürften die meisten hier machen.


Wenn ich Deinen Post richtig interpretiere, möchtest Du zum tieferen 
Verständnis richtig einsteigen.
In diesem Fall empfehle ich das Datenblatt zu Deinem AVR und die 
offiziellen DMX-Spezifikationen.
Die ANSI E1.11 kannst Du als Draft bei Soundlight laden.
Für die E1.20 sind ein paar Euro an die ESTA fällig.

Diese Dokumente haben mir damals viel gebracht.


Falls der Post Ironie war:
Du hattest falsch "abgeschrieben" und ich wollte einen Tipp geben, wie 
Du Dir das "Abschreiben" komplett sparen kannst. Für das, was Du 
scheinbar tun möchtest, lege bitte meinen Code beiseite und beginne 
selbst auf Basis der Grundlagen (s.o.)
In einigen Monaten können wir dann vielleicht etwas voneinander lernen.


Viel Erfolg und Alles Gute bis dahin,
Hendrik

PS: Mit Minti hatte ich damals an älteren Versionen gearbeitet, die ich 
später noch etwas verbessern konnte. Es war ein schönes Arbeiten und ich 
finde es schade, dass er nun scheinbar weniger Zeit für seine Site 
findet.

Ansonsten auf den ersten Blick:

Prüfe mal die Baudratenzuweisung: Wenn in UBRRL 1 steht, ist sie OK.

Du überschreibst Pin2 an PortD. Hängt da noch die Empfangsumschaltung 
dran oder nicht?

Der Sprungvektor im Falle eines Overruns fehlt. Momentan dürfte alles ab 
der Stelle daneben gehen.

Mir ist so, als gäbe es damals Probleme mit dieser Art 16bit-Variablen 
zu inkrementieren. Teste lieber explizit auf Null.

Du speicherst alle Bytes ab Startadresse bis zum nächsten Break.

Das wäre dann der DMX Part.

(Sieh also bitte ein, dass da noch mal simuliert werden sollte...)

VG,
Hendrik

Moin,

also jetzt wirklich DANKESCHÖN! Das ist eine Antwort mit der man weiter 
machen kann!! Danke für den Tip.

Ich will ja nicht das Rad neu erfinden. Ich möchte verstehen was da 
passiert damit ich auf deinem Programm aufbauen kann. Deshalb möchte ich 
versuchen das selber zu schreiben!!!

Kurz zu DMX:
der aufbau ist mir eigentlich soweit klar. aber wenn der die datenbytes 
der kanäle sendet ist doch zwischen den bytes auch ein Brake oder nicht. 
somit empfängt der uc ja immer nur einen "kanal" und dann den nächsten!! 
Der Wert des Kanals steht dann in UDR oder?? Somit springt der uc nach 
empfangen aus der ISR raus und dann beim nächsten kanal wieder rein 
oder???

Zwischen den Daten wird kein break gesendet. DMX sieht so aus:

IDLE  (high-kann, muss aber nicht)
BREAK (low-mindestens 88µs, also so lang wie 2 Daten, µC "sieht einen 
Framing Error, darauf wird synchronisiert)
MARK AFTER BREAK (high-ich glaube so um die 8µs)
STARTBYTE(muss immer 0 sein)
Daten (zwischen 1 und 512)
IDLE  (high-kann, muss aber nicht)

usw...

MW

Aber nach jedem Byte springt der uc wieder aus der ISR raus und dann 
wenn RXC wieder gesetzt ist wieder rein und das ist dann einfach der 
nächste Kanal oder?????

Richtig, wie ich schon schrieb musst du auf das FE-Bit synchronisieren 
und in jedem Interrupt einen Zähler inkrementieren. Entweder das ganze 
Paket abspeichern oder den Zähler mit der eingestellten Startadresse 
vergleichen und dir die Nutzdaten rausfiltern.

MW

Also ich hab jetzt mal den rxd vom Henne versucht und das klappt genauso 
nicht.

ich setzt einfach den PinC0 -> somit DMX adresse 1 oder???


aber der compiler springt dann immer weiter!!!!

Also vom DMX Ablauf her:

RXC + FE wird gesetzt -> UCSRA wird gespeichert -> reti -> RXC wird 
gesetzt -> UDR wird gelesen und verglichen -> startbyte = 0 -> reti -> 
RXC wird gesetzt -> UDR Daten gespeichert und dann startadresse 
vergleichen -> wenn gleich, UDR in dmx_field speichern -> reti -> RXC 
wird gesetzt -> UDR Daten in dmx_field speichern -> .... bis zur letzten 
dmx-adresse


So ungefähr sollte es doch ablaufen oder lieg ich da falsch????
Also nur die Routine was beim DMX empfang abläuft und nicht was genau 
mit der verarbeitung passiert!

Ja schon klar wenn ich 5 kanäle hab dann speichert der auch nur 5 kanäle 
im sram ab.

So simulier ich des die ganze zeit schon einmal mein programm und einmal 
das rxd programm, bei meinem funktioniert in der simulation alles die 
daten werden gespeichert und weiter verarbeitet. Aber wenn ich es auf 
den uc lad kommt da nix raus auf dem led port bzw ich komm gar nicht 
soweit!

also den ersten punkt hab ich schon mal gefunden im Code vom Henne:

1

ifdef USE_DIP

2

    sbr    temp, (1<<0)     ;hab ich nur zu testzwecken, DMX-Adresse = 1

3

    out    PinB, temp

4

    in     XL, PinB         ;get start address

5

6

    com    XL               ;muss raus, dann geht es!

7

8

    clr    XH

9

    sbic  PinE, PE2         ;9th bit; hier steht normal sbis aber er sollt

10

    inc    XH                "skippen" wenn das bit nicht gesetzt ist

Irgendwie komm ich nicht mal bis zum frame Error. Welche Fuses habt ihr 
denn da gesetzt für den externen quarz???

Aber ich find zu dem quarz kein vernünftiges datenblatt, wo drin steht 
welche START-UP-TIME und ADDITIONAL-DELAY er hat.

Hier geht es um das CKSEL0 und die SUT Bits

Ja schon klar aber woher weiß ich welchen SUT wert ich nehmen soll 258CK 
oder 1K , 4,1ms oder 65ms??

also inzwischen komm ich bis zum Frameerror! den erkennt er richtig aber 
das startbyte noch nicht wirklich!!

kann das an der Quarzeinstellung liegen?? Weil im Simulator funktioniert 
alles einwandfrei!

OK - ganz von vorn.

Falls Du meinen Transceiver nutzt, bügle eine fertige Firmware drauf und 
bringe die erst mal zum Laufen.

Dann stimmen schon mal Verkabelung und Fuses.

Wenn Du auf ein anderes Target aufsetzt, nutze erst einmal dessen 
fertige FW. (Wenn Du völligen Eigenbau betrieben hast, kann ich Dir nur 
noch viel Glück wünschen...)

Dann schaust Du, ob Daten eintrudeln.
Dann schaust Du, ob ein FE kommt.
Dann schaust Du, ob Startbytes korrekt erkannt werden.
Dann guckst Du Dir die Adressierung an.
Dann wird das Puffern der Daten interessant. (Derzeit würde ich noch die 
Finger vom SRAM lassen...)

und vorher simulierst Du die gesamte FSM komplett durch.

Und wenn Du dann immer noch nicht lauffähig bist, schreibst Du den 
aktuellen Code vollständig hier rein.

(Ich neige auch oft zum Raten und bin ziemlich oft damit auf die Fresse 
geflogen - sei klug und systematisch ;-)

Viel Erfolg,
Hendrik

PS: Am WE habe ich vor, im Forum von DMXControl interessierten Leuten 
das Arbeiten mit meinen C-Libs zu erklären und gemeinsam was zu proggen.
(Das ist zwar C und nicht AVRASM - aber vielleicht könnte das was für 
Dich sein...)
Voraussetzung ist natürlich, dass Du bereits die fertigen FWs korrekt 
geflasht bekommst - sonst machen mich wieder einige mit den PonyProg 
Dongles wahnsinnig ;-)

Ein oft gemachter Fehler: DMX + und - Leitung vertauscht. Bitte prüfen.

MW

UBRRL= 3;

Rest dürfte passen.
Alternativ F_OSC auf 16000 [kHz] setzen.

Mich wundert, dass bislang niemand "rtfm" gepostet hat. Find ich nett.

VG,
Hendrik

Ansonsten ist übers Wochenende bei DMXControl ein kleines Tutorial über 
DMX-Empfang mit der C-Lib entstanden. Ich denke, mehr geht nicht.

(Somit ist dies mein letzter Post zu den Libs.)

http://dmxcontrol.de/wbb2/board.php?boardid=24&sid=f82c2c770d4343b7567488595fd49573&PHPSESSID=9e035de7524052639732023ba0aaac35

(Falls der Link nicht geht: Forum->Selbstbau)

Rauskram,

auch bei mir klappt der DMX Empfang nicht wie er sollte. Ich habe mich 
an die C Version gehalten und das ganze für einen AT90PWM3B 
umgeschrieben. Nur wird bei mir nie die ISR für den USART ausgelöst. Das 
einstellen der Adresse klappt und auch läuft mein Programm an der Stelle 
vorbei, wo der Reciever enabled wird. Dann habe ich mir mal in die ISR 
Routine als erstes an Anweisung geschrieben um einen Port zu setzten. Da 
dieses nie geschieht, gehe ich davon aus, daß die ISR auch nie ausgelöst 
wird. Ich verstehe auch momentan nicht, welche Bedingung erfüllt sein 
muss, damit die ISR überhaupt ausgelöst wird. Vielleicht kann mir da 
jemand von euch einen Hinweis geben, wie das ganze funktioniert.

Grüße Christian

Also,

ansich habe ich den Quelltext der C Version genommen und da werden die 
globalen Interrupts per SEI auch aktiviert. Ansonsten ist eigentlich 
alles wie im Quellcode. Ok man musst ein wenig anpassen, damit die 
Register mit dem AT90 übereinstimmen, aber das Compilieren geht 
fehlerfrei. Dennoch spring das Programm nicht in den USART Interrupt und 
ich weiß nicht warum. Auch verstehe ich die Funktion halt nicht ganz. 
Was mir zum Verständiss fehlt, ist der Punkt, wo der Interrupt in 
Quelltext ausgelöst wird.

Grüße Christian

So,

hier habe ich mal den Quelltext dran gehangen. Wenn man daß mit dem 
original Quellcode vergleicht gibt es eigentlich keinen großen 
Änderungen. Das Einlesen der Startadresse ist etwas anders, liegt daran, 
daß ich über 2 Ports verteilt gehen musste. Ansonsten ist es die selbe 
Technik wie im Original Quellcode für das neunte Bit der Startadresse. 
Das Einlesen klappt auch fehlerfrei. Ich hatte das mal anhand von Ports, 
die ich bei bestimmten Adressen habe setzten lassen getestet.

Die einzige wirkliche Änderung betrifft das UCSRC Register denn der 
AT90PWM hat im gegensatz zum 8515 dort kein Bit für URSEL. Da die 
Initalisierung dort aber den selben Modus herstellt wie das URSEL Bit im 
8515 habe ich dort keine weiteren Maßnahmen getroffen. Vielleicht ist 
das ja der Fehler und ich muss dieses unbenannte Bit7 trotzdem nochmals 
setzten, was ich mir aber nicht vorstellen kann.

Zur Hardware, meine Platine ist per Optokoppler und DC/DC Wandler 
galvanisch vom DMX Bus getrennt. Ich weiß aber das ein DMX Signal am RX 
Pin ankommt. Oszilloskop sei dank, von daher schließe ich einen Fehler 
in der Hardware mal aus.

Grüße Christian

So,

jetzt wird schonmal die ISR ausgeführt. Frag mich nicht woran es genau 
gelegen hat. Ich habe einemal das Bit7 im UCSRC Register von Hand auf 
Null gesetzt und seitdem läuft die ISR. Die Bits des DMX Stream werden 
wohl richtig erkannt, zumindest kann man Ports zu ihrem Eintreffen 
toggeln. Einzig die Daten werden nicht richtig gespeichert. Ich 
überlege, ob ich das DMX Protokoll nichg genau genug einhalte. In meiner 
Schaltung gibts eine galvanische Trennung. Der Optokoppler ist ein Open 
Collector, der dann gegen Masse durch Schaltet. Da man zwar im Atmel 
einen Pull-Up aktivieren kann um den Open Collector zu versorgen man 
dann aber ein invertiertes Signal am Pin hätte, habe ich noch einen 
Inverter dazwischen geschaltet. Muss ich mir mal auf dem Oszi genauer 
angucken wie da das Signal aussieht. Vielleicht stimmen die Timeings 
nicht mehr. Ansonsten währe es auch mal ganz interressant zu wissen, ob 
man die Routine auf ein invertiertes DMX Signal umprogrammieren kann, 
würde etwas Schaltungsaufwand sparen.

Grüße Christian

Stimmt wohl,wohlnur habe ich momentan einen 6n136 drin und der hat 
keinen nach außen geführten emitter, sondern ist intern auf Masse 
geführt. Und ehe ich einen neuen optoklopper raussuche, hätte es ja 
einfacher sein können den quellcode anzupassen. Aber dennoch Danke, 
werde dann mal die Hardware anpassen

Moinsen,

ich krame das Thema hier nochmal raus. Inzwischen habe ich meine 
Hardware angepasst und mein Signal nach der galvanischen Trennnug per 
Optokoppler nochmal invertiert. Am RX Pin meines AT90PWM kommt also das 
DMX Signal jetzt genau so an, wie es sein sollte. Trotzdem klappt die 
ganze Sache immer noch nicht. Ich habe mir in den Quellcode mal ein paar 
Flags gesetzt, die mir Pins toggeln. Den Frameerror am Anfang eines 
Frames erkennt die Routine wohl noch richtig. Das Break danach schon 
nicht mehr. Jetzt kommt das komische an der ganzen Sache, wenn ich meine 
DMX Karte richtig stresse und auf allen 512 Kanälen einen Wert ausgeben 
lasse erkennt er auch das Break, Startbyte jedoch immer noch nicht. 
Meine Überlegung währe jetzt, daß meine Bautrateneinstellungen 
vielleicht nicht richtig sind. Könnte da mal jemand einen Blick drauf 
werfen?
Ich sehe mal zu, daß ich im Laufe der Woche mal eine paar Bilder vom 
Signal mit nem Oszi mache und hier rein stelle.

Grüße Christian