Beiträge von Henne

Ich finde es ehrlich gesagt ganz witzig, dass hier zunächst allgemein gefragt wird, ob das Teil was taugt.

Dann wird ohne Sinn und Verstand bei eBay drauflosgeschossen.

Dann stellt man fest, dass man eigentlich nicht den geringsten Plan von dem Gerät hat - aber das Forum wird's schon richten :roll:

Wenn man ein Gerät nicht steuern kann, weil es keinen Controller gibt (bzw. nicht dabeiliegt) und das eigene Wissen nicht ausreicht die Situation zu ändern, dann sollte man die Finger davon lassen...

Vielleicht seh ich das ja zu kritisch - aber meine Sorge ist, dass zukünftig dann irgendwelche Kinder defekte Macs, defekte amtliche Dimmerpacks und Endstufen schießen und hier dann aufgepeppelt werden wollen. Durch dieses non-stop GratisDebugging würde das Forum ziemlich ungenießbar für mich werden...

Es werden glaube ich Asynchronmotoren verwendet. Auf Frequenzumrichter sollte man deshalb verzichten können.

Meist werden Funzeln über interne Fades gebremst um die Wendeln etwas zu schonen und auch um eine gleichmäßigere stromaufnahme zu gewährleisten. (Ich selbst glaube zwar nur an Surges bei extrem schnellen Kaltstarts, wo der preheat schon gute Arbeit leistet...)

Implementiert man keine Fades sondern gibt sofort den Sollwert drauf, hast Du Deine Geschwindigkeit *g*

Noch schneller ginge es, wenn Du den Abstand zwischen Ist- und Sollwert bestimmst und dann zur 'Beschleunignung' falls nötig eine Halbwelle Vollgas draufgibst...

Ich halte das für kein Qualitätsmerkmal - aber Du wolltest ja wissen, wie man sowas machen kann...

Ein guter Dimmer sollte nicht stören, nicht übermäßig schwer sein (Zielkonflikt!), nicht kaputtgehen - und falls doch gut zu servicen. Dazu zähle ich auch Ersatzteilverfügbarkeit (zB: der MCUs, PSUs, ...)

Ich weiß, dass es nicht 100%ig passt - aber:

ElektroG / WEEE

Wie geht Ihr damit um? Laut momentaner Auslegung sind Platinen und Bausätze nicht betroffen, da sie keine fertigen Geräte sind. Allerdings scheint selbst diese Info nichts verbindliches zu sein, da Elektor soweit ich weiß noch keine befriedigende Antwort bekommen hat.

Ich selbst sollte mit meinem Transceiver momentan noch ganz sicher sein - setze aber auf Lagerabverkauf und warte dann erst mal ab, wie sich alles entwickelt.

Wie schaut's bei Dir aus, Michael, mit Deinem Interface? Augen zu und durch? Mit dem Argument der Unverhältnismäßigkeit die EAR kontaktieren?

Was ist mit Dir Carsten? Der CCFL-Dimmer sollte ja schon in der Fertigung sein... CE-Konformitätserklärung sollten wir auch noch hinbekommen...

Manu sollte es mit Ihren Amps ziemlich erwischt haben: Die fallen voll unter das ElektroG - somit sollte Sie als Herstellerin b2c-Mitglied bei der EAR werden müssen (mit all den verbundenen Kosten und Späßen...)
Ist es Dir möglich, die Fertigung abzutreten und als Lizensgeber (à la RAMBUS) über die Runden zu kommen? (Wäre jedenfalls zum Heulen wenn eine völlig neue Generation Amps mit unbeschreiblicher Entwicklungsarbeit an der Containerlotterie zerschellen würde )

Markus (DMX4All) macht mir auch etwas Sorgen: Er kündigt mit Begeisterung neue Geräte an und hat sich in der Vergangenheit von Platinen/Controllern zu Fertiggeräten umorientiert (mittlerweile gibt's nicht mal mehr den Schaltplan in der Doku...). Da die Einrichtungskosten im Verhältnis zu den Stückzahlen ziemlich heftig sind, dürften seine Gewinnspannen sich wohl auch eher in Grenzen halten. Mal schaun, wie er die Belastung puffern wird...

Grüße, Hendrik

(sorry - aber irgendwie dachte ich, das ist wichtiger als die Detektierung eines FEs...)

hatte mich in deinem post verlesen - sorry

Selbst 2USARTs sind etwas dünn, wenn man mehrere Universes verrouten will. So hätte er 1xIN und 1xOUT per Hardware. meines Wisssens hatte das Teil aber ein paar mehr :wink:

Wieso gibt's nicht nen mega8 mit 4USARTs - das wär doch mal was Feines *g*

Splitter/Bosster dürfen dumm sein und müssen sich nicht ums Signal kümmern (Break...)

Anders sieht das aus, wenn Du Streams routen oder mergen möchtest. Vielleicht solltest Du also kurz erwähnen, was Du wirklich bauen möchtest...
Bei letzterem halte ich den Mangel an weiteren USARTs für ein Problem, da Soft-USARTs ziemlich die Performance drücken und das Timing nicht völlig unkritisch ist. (Hier bewundere Markus (DMX4All) für den Gateway.)

Grüße, Hendrik

Es gibt Sender, die es nicht für nötig halten, das Signal zu loopen sondern nur bei Änderungen eingreifen.

Dies entspricht nicht den Vorschriften - meine ErrorLED meldet sich und hakeln tuts auch mal... Desweiteren wird oft das Signal per Firmware generiert (Soft-USART): Wenn man nun die Schleifen einfach generieren lässt ohne die Timings später zu simulieren / messen bzw. IRQs dazwischen funken lässt, kommt dann auch ein ziemlicher Datenmüll raus.

Die Frage ist, welcher Transmitter in diese Ecke gehört und welche state machine mit so etwas noch am besten klarkommt...

stop1 -> 8n1
stop2ad -> 8n2 (mit DIPs)
9n1 -> 9n1

Bitte die 9n1 noch einmal ziehen - in der alten könnte ein Bug gewesen sein...

That's all (es sei denn, Du willst gleich noch LCs Code mitnehmen )

unter welcher Platine? (wenns meine war, wurde ich ziemlich beschissen...)

Such Dir einfach was aus.
Am praktischsten wären vielleicht die drei machines aus diesem Thread (8n1, 8n2, 9n1) - dann haben die anderen auch was davon...

Die 9n1 hier sollte zZ. noch einen kleinen Bug haben, der uU zu einem Deadlock der machine führt - wird aber heute noch behoben.

PS: Hättest Du denn unbedingt für das bischen Gebastel das schöne Gehäuse zerfräsen müssen

Weil Jeremy es wieder angesprochen hat:
"Dunkler Text auf hellem Hintergrund"

Da würde ich gerne mal mit Euch drüber diskutieren.

Für Print trifft diese Behauptung sicherlich (vor allem aus Kostengründen) zu - für Pages nicht.
Mir ist aufgefallen, dass viele Bilder durch eine helle Umgebung (Hintergrund) ihre Leuchtkraft verlieren. Ein kleineres Bild mit z.B. einem Argonlasertunnel und einem Dutzend Heads wirkt auf schwarz kräftig, satt und intensiv - auf weiss hingegen trüb, dunkel und deplatziert.

Der Hintergrund muss auf allen Seiten einheitlich sein - also fallen schwarze Gallerien und weißer Content völlig aus (wirkt grauenhaft).

Der Kompromiss (grauer Hintergrund) macht jegliche nennenswerten Kontraste zu nichte.

Zur Lesbarkeit: Bei einer Recherche musste ich mal wirklich viel am Bildschirm lesen - bei weißem Hintergrund, Arial black, Größe10 taten mir nach 20Seiten die Augen ziemlich weh. 50 Seiten schwarzer Hintergrund, Arial dunkelrot, Größe12 war dies komischerweise nicht der Fall (auch wenns scheußlich aussah...)

Hendrik

LC - das ist genial :shock:
...ich hatte immer nur die 3p Duos im Kopf...

Für Duo brauch ich mehr Pins...
ist doch blos ein mega8515

ginge auch noch allgemeiner:

Wenn die Rx-ISR häufig angesprungen wird, wird wohl irgendein Signal am RxD-Pin wackeln.
Wenn die Daten aber niemals Break und SB durchstehen, stimmt wohl etwas mit dem Signal nicht: Nun weiß ich zwar nicht, ob da einer ein Micro oder MIDI angeschlossen hat - aber die Wahrscheinlichkeit einer Verpolung ist ungleich höher

Wenn das signal diese Tests übersteht, haben wir es wohl mit phasenkorrektem DMX zu tun

Aber was soll denn noch alles Blinken?!? (Man muss die ErrCodes ja auseinanderhalten können) Aber für sämtliche LCD-Geschichten wäre das wohl ganz hilfreich...

Ansonsten - hier meine Codes:
0b10101010 -> zc-Error (dimmer only)
0b00000001 -> no DMX (oder verpolt)
0b00000101 -> address error
0b11111110 -> Temp

Falls der blaue der erste war: nach Erreichen der Startadresse nicht ausgewertet sondern nur state verändert?

Grüße, Hendrik - der schon gespannt auf Carstens machine wartet (aber eigentlich noch ganz angetan von der 9n1 ist...)

MAB ist 8µs HI. IDLE ist beliebig HI.
Ich erhalte halt einen echten FE nach detektiertem Break (vielleicht ist ja auch der Break eine Ecke länger, weshalb es da knirscht - jedenfalls muss ein FE after Break ignoriert werden.)

Andere FE jedoch eher nicht: Bis sich der USART wieder fängt und synct kann ich einen ch verloren haben. Also warte ich lieber auf einen Durchlauf ohne Störungen (wozu gibt's sonst eine möglichst hohe refresh rate, wenn nicht den Bruch zu verwerfen?)

Ich selbst kannte diesen Trick erst von Michael - und der hat ihn nicht vollständig implementiert.

So hier die finale (ultimative) state machine :
1. stop bit = LO -> Break oder FE
2. stop bit = HI -> FE
data != 0 -> FE

Der MAB erzeugt einen nach obigen Kriterien ungültigen zweiten FE. Deshalb darf ein gültiger Break nicht von einem folgenden FE gekillt werden.

Hier der Code: http://www.hoelscher-hi.de/hendrik/share/9n1.zip

Das war's von mir. Es wäre nett, wenn Ihr mal drüberschauen könntet, da bis auf den FC alles drin ist...

Stopp - alles falsch. Heute Nacht ist mir Folgendes aufgefallen:

FE: Das Frame stimmt nicht mehr, da ein bit verschluckt oder doppelt gezählt wurde.
Break: Ein LO-Pegel über >88µs

Die 9n1 Variante muss in Wahrheit (vielleicht nur bislang falsch von mir verstanden) so aussehen:

FE: 9.bit LO, 10.bit HI (-> ein bit daneben)
BRK: 9.bit LO & 10.bit LO (FE) (-> beide bits müssen LO sein, da zwei Frames verschmolzen werden)

Damit hat das Ding doch das Potential zusammen mit dem SB einen Irrtum nahezu unmöglich zu machen... Ich stells heute mal rein.

Stefan:
Ich schick Dir 'ne 3.01 rüber wollte ich damit sagen. Was ich hören will: " A funzt nit, B geht, C hakelt, D ist auch nicht das wahre, E-H sind super, etc..." Da weiß ich dann, wo ich ugf. stehe.

Michael:
Na gut. Also explizit :wink:
Der FE wird durch ein falsches erstes stop bit ausgelöst. Wenn ich also 8n2 wähle und habe einen FE, bedeutet dies, dass das 9.bit LO ist. (10.bit wird nicht beachtet)

Du stellst nun 9n1 ein und bist von dem Pseudo 9.bit (= erstes stop bit) begeistert, was Du immer auf HI checkst, da sonst FE bzw. Break.
Nichts anderes macht der FE in Hardware - ich halte beide Methoden für identisch, blos die im DS vorgeschlagene für etwas eleganter.

möglicher Unterschied:
Du wertest das 2. stop bit FE mäßig aus: Wenn dein Signal also gleich 2bits verschluckt, liegst Du richtig und ich falsch. In diesem Fall halte ich aber alles für zu spät, da dann wahrscheinlich auch sonst bits vertauscht und Frames gesprengt werden...

@LC: ich versuche mal konkret einen Fehler zu entwickeln, der Deine state machine sabotiert. Wenn ich daran scheiter bzw. sie sich nicht verschluckt, wäre das ziemlich ultimativ