Beiträge von marcoboy

Das ist das Panel an sich. Also alles das was am Empfänger dran hängt und das zusammenhängende Board bildet. Damit wird das Board adressiert also welche Empfänger sich welche Pixel vom Sender abgreifen.

Der LSD hat ja nicht nur 16x16 Pixel -> eine Platte hinter dieser weitere hängen pro Row. Die Daten werden pro Row eingeschoben und das System muss wissen wie weit es schieben muss. Die Row wird per Adressdecoder ausgewählt da offenbar 16 Rows nicht ausreichen (4bit ABCD). Deswegen wird der Adressraum mit dem HC138 erweitert.

Ob das Setup richtig ist kann man aus der Ferne nicht sagen. Du musst es aber im Empfänger speichern und auch das Setup . Also der Empfänger muss wissen was dran hängt und wie der patch ist. Das sind zwei unterschiedliche Setups.

Auch ist nicht auszuschließen das der HUB falsch beschalten ist. Das kann man aber mit einen Generator ausprobieren. ROW fix auswählen, CLK anlegen und R,BG auf high sollte sich was einschieben. Dann sieht man auch wie sie verschalten sind. Solch einen Testmode hat der Empfänger auch. Das intelligent Setup ist ja nichts anders, du gibst der Software an was du siehst und die setzt den Mode. Das die Setups vom Hersteller nicht funktionieren deutet auf einen Verdrahtungsfehler hin . Das Setup biegt es jedenfalls wieder so hin das es passt .

Ich habe die AVB Tauglichkeit von Apple mal untersucht und bin positiv überrascht. Man kann sagen was man will, es hat auf anhieb funktioniert. Die Geräte werden gefunden und man kann sich mit diesen verbinden, das Problemlos. Auch der MAC lässt sich in ein AVB Endpoint verwandeln

. Allerdings ist es mir nicht gelungen mehr als 16ch zu streamen obwohl im Menü 64ch als auswählbar angezeigt werden.

Man muss nicht mal sonderlich tief in die Tasche greifen, ich habe hier ein MacBook Air mit Thunderbolt Ethernet Karte. Die externen Karten, außer USB sind wohl alle PTP Fähig.

Das Problem bei der 3,5mm Klinke ist das sie bei bei Künstlern fast immer kaputt ist wenn sie so etwas benutzen.

Die Lösung wäre den USB Anschluss im Host Modus zu betreiben um eine Soundkarte anzuschließen.

normaler UDP Steam wenn >100ms kein Problem sind. Ich würde aber zu einen wlan Router greifen der den neusten Standard unterstützt und somit in der Lage ist solch einen Stream zu priorisieren. Außerdem würde ich die Buffer sehr groß machen. Die 100ms sind trotzdem nur schwer zu erfüllen schätze ich.

Das Problem beim Wlan ist das es anders funktioniert als das Kupfer. Nicht nur weil es durch die Luft geht sondern auch wer wann senden darf oder auch nicht. Das führt dazu das das ganze zeitlich nicht planbar ist.

Das ganze führt schon selbst bei simplen Sachen wie Artnet zu Verwerfungen die nicht unerheblich sind. Nur dort fällt ein fehlenden Frame nicht auf.

Es gibt zwei Versionen von der PCB. Die eine ist Analog und die andere hat einen µP drauf. Sie machen aber genau das gleiche.

Was soll das bringen ? Schau dir die Ansteuerung vor den Koppler an. Den Ozzi auf "Netz" triggern. Dann sieht man sofort was los ist.

Aber Vorsicht die andere Seite hat Netz Potential !

Spannungsversorgung wird ich als erstes prüfen, da bei manchen Geräten die PCB an zu heißen Orten geparkt wurde. Davon geht manchmal der Trafo kaputt.

Der vermeidliche Transistor ist ein Thyristor und der wird von einen Optokoppler angesteuert. Meist ist dieser auch hinüber. Was aber auch fehlen kann ist der Sync vom Netz.

Ich hoffe du hast die Pumpe auch richtig angeschlossen ? Das Board muss für alle Produkte herhalten. Dort gibt es auch einen Lüfteranschluss., nicht das du da die Pumpe angeschlossen hast.

Die extra PCB ist die Ansteuerung Push/Pull da man für die FETs hohe spitzen Ströme braucht.

Die Dinger sind alle Parallel geschaltet und deswegen selektiert. Wenn einer anders reagiert fließt durch diesen mehr Strom und dieser stirbt. Die anderen müssen dann den Strom mit tragen und sterben dann ebenfalls. Die Dinger kommen aus China und da weiß man sie was wirklich da verschraubt wurde. Deswegen müssen sie diese ja auch selektieren, sonst knallt es sofort . Kauft man Originale ist die Streubreite der Typen geringer.

Es wird wohl ein IGBT sein da diese bei hohen Strömen einen geringeren RDSon besitzen.

Da kann man eigentlich fast alles einsetzen was die Spannungsebene und Strom verträgt.

Das Ding funktioniert wie ein geschalteter Widerstand die IGBT schließen den Brückengleichrichter kurz und schon kann der Strom auf der Eingangsseite fließen.

Es gibt Hoffnung in Sachen einfache AVB Switch http://www.microchip.com/wwwproducts/en/KSZ9567 offene Doku und Driver. Die Qual mit Marvell hat eine ende .. und ich darf endlich wieder darüber reden

Das Ding kostet ca $13 und ist kein BGA . Ich habe mal ein Board vorbestellt.

So ich habe das mal auf einen 8bit AVR portiert und einen LED Dimmer gebastelt . Die Hardware stammt aus einen damaligen Projekt.

Universal Arduino shield

Siehe da auch das läuft ...

Zitat von e-on

Kann mir jemand sagen was das soll ?

Lenovo Win 7 32bit

Mobile Intel(R) 945 Express Chipset Family

Ja dein Grafikartentreiber unterstützt die Funktionen nicht .

Das Problem ist folgendes wie es auch heißt (OpenGL,Direct X etc.) sind Schnittstellen zur Hardware die durch diese Technik vereinheitlicht wurden.

Beispiel: drawRectangle(startX,endX,startY,endY); Zeichnet ein Rechteck in den Bildschirmspeicher. Was dazu Hardwareseitig nötig ist macht dann der Hersteller des Treibers. Also in welches Register etc. muss man schreiben damit auf dem Bildschirm das Rechteck zu sehen ist. Die Schnittstelle zu OpenGL, DirectX ist im Grafikkartentreiber. Das Programm spricht diese an und auf dem Bildschirm ist das gewollte zu sehen. Das hat einen Riesen Vorteil da man sich nicht mit der Hardware beschäftigen muss und die Ausgabe auch relativ unabhängig ist von der Hardware . Leider ist die Qualität sehr stark davon abhängig wie gut der Hersteller diese Schnittstelle in seinen Treiber implementiert hat.

Dlive benutzt Funktionen die der Treiber nicht unterstützt. Das tritt meist bei billig Geräten mit Intel Karten auf, die sowie so schon eingeschränkte 3D Möglichkeiten mit sich bringen.

Abhilfe gibt es kaum, da man so auch das Verfallsdatum von Hardware beeinflussen kann.

Gute Programmierer passen aber die Programme an, das Opfer was man dann bringen muss ist das die Oberfläche dann nicht so schön ausschaut. Als Schatten fehlen etc..

Nö muss nicht das ginge auch mit Layer 1 solange die Daten Ethernet konform sind. Die Switch muss natürlich damit umgehen können.

Aber das was du vor hast (AES50) klappt nicht da dies nicht Ethernet konform ist.

Solche Lösungen gibt es schon, diese sind aber im Verhältnis zum Kabel zu teuer. Das Problem ist Steckverbinder und Kabel so zu gestalten das sie den Belastungen stand halten.

Dadurch werden sie schwer und teuer.

Die Frage ist er was und wie lässt sich in deinen DMX Programm etwas per MIDI Steuern.
Da wird es schon recht komisch, ohne Möglichkeit für eignende Scripte kommt meist nicht viel dabei heraus.

Wer sagt das ? So lange es die Brenner gibt wird es auch Zündgeräte geben. Da die Mengen nicht mehr so hoch sind Dank LED Technik versuchen einige Hersteller ihr Angebot zu vereinfachen. Bei dem hier wüsste ich es nicht. Es kommt eben auf die Menge an . Welches Zündgerät geeignet ist sagt dir der Hersteller des Brenners.

Ich habe noch 5 hier liegen, musst du dich melden wenn du welche haben willst. Neue werde ich voraussichtlich aber nicht bestellen, bzw. alles >50 Stk. .

Es ist vollbracht die beiden Projekte sind verbunden. RDM läuft nun auch über Artnet. So wirklich habe ich noch keine Verwendung, Hardware hierzu zu Entwickeln ist mir zu risikoreich . Zumal es in dieser Richtung ja schon wenige Sachen gibt. Wenn jemand Ideen hat immer her damit. Machen kann man vieles Hier sind alle 3 Projekte dran beteiligt. RDM Device, RDM Controller, ArtnetNode. Das Device wäre mit Einschränkungen auch auf einen AVR lauffähig., bei den anderen Projekten ist der Speicherverbrauch zu hoch. Gerade das Discovery benötigt je nach Baumstruktur Speicher, aber wir reden hier über byte bis kbyte . Beim AVR ist davon als Sram zu wenig vorhanden, für die suche wie auch das speichern der UID Liste.

Ein Splitter wäre auch sehr leicht möglich hier muss man aber unterscheiden.

A: billige Lösungen die die Richtung nur Umkehren.

B: aufwändige mit eigenen Discovery auf jeden Port.

Das mit der Richtung umkehren klappt mit einen AVR und etwas Logik.
Die andere Lösung ist aufwändiger und je nach RAM und Uarts am µP begrenzt auf ewt. 8 Ports.
Ewt. Portiere ich das auch auf den Xmos. Dann sind ohne weiteres 32 Universen und mehr möglich

Logisch kann man das trennen aber es überfordert den Anwender erheblich.

Gehst du technisch eine ebene tiefer merkst du das dass eben nicht mehr so unproblematisch ist. Ich sagte ja " es sieht auf den ersten blick leicht aus" Will mich auch nicht so tief in technische Kram vertiefen, aber so kannst du die nötigen Bandbreiten nicht ausrechnen. Es ist fast unerheblich ab 2 channels oder 8 channels im Stream sind. Das ist durch den packet Header bedingt. Die 30% waren nur symbolisch gemeint um das Problem zu verdeutlichen. Das mit der Latenz ist so ein Sache. Es funktioniert nicht wenn du das Signal ohne großen Buffer wieder auf der anderen Seite decodieren willst. Das Sample muss zur zeit x vorliegen sonst kommt es bei der DA Wandlung zu einen Problem. Wie groß willst du den Buffer machen um sicher zu gehen das auch bei extremer Auslastung das Paket rechtzeitig durch kommt ? Ohne irgend etwas zu priorisieren zu müssen. Bei AVB hast du die möglich der Switch zu sagen A: 2ms B 50ms. Ohne PTP und damit synchrone Uhren muss der Buffer recht groß sein. Die Kunst ist es ja dem Frame die Zeit mitzugeben an dem er ausgeben werden muss. Der Rest muss nur sicherstellen das es auch wirklich vorhanden ist. Sonst -> Plop... Das heißt das Zeitfenster wann was da sein muss ist fix durch die Samlpingfrequenz und somit nicht variable ohne Buffer.

Siehst du und das meinte ich auch, bei der Mehrzahl der Kunden reicht die XLR Strippe. Ich glaube kaum das josefbecker einen anderen Kundenkreis im blick hatte.

Natürlich kann man so etwas auf AVB oder Dante entwickeln. Da frage ist nur Aufwand und nutzen.

Toll den alten BOS Hörer verwertet, der ist aber weniger cool als der im Bild

Aber der Link offenbart etwas anderes. Dort wird auch ein digitales Intercom feil geboten. Die Übertragung läuft per RS485 mit 5mBit und Handshake.

Das Problem ist das der Anwender völlige koexistenz zu anderen Protokollen erwarten würde. AVB und Dante auf einen Netzwerk wäre ohne Konfiguration der Switch schwer möglich . AVB würde immer gewinnen, da es selbstständig Bandbreite reserviert.

Es würde keiner akzeptieren 30% oder mehr Bandbreite an das Intercom abzugeben. Die Lösung wäre viel zu teuer,speziell und kompliziert.

Fazit -> lassen wir es und ziehen lieber einfach ein XLR Kabel .

Das Ding so flach zu legen ist der Standard Fehler. Beim zuklappen kommen wenn man nicht aufpasst die 5V gegen das Gehäuse.

An den Klassiker haben sich schon viele eine goldene Nase verdient.

Beim DJM800 sind diese auch noch in SMD ausgeführt, somit für den Anfänger kaum noch zu wechseln.

Nunja ein Intercom besitzt eine ganz andere Netzwerkstruktur wie ein Audionetzwerk. Was auf den ersten Blick einfach erscheint ist wenn man sich das ganze mal überdenkt so ziemlich komplex.

Denn egal wie muss der Stream Master -> Teilnehmer per Multicast verteilt werden. In die andere Richtung wird es dann schlimmer Teilnehmer-> Master sind das nur Unicast Streams. Am Master ist hierzu pro Teilnehmer eine Node nötig mit eigener MAC usw.

Klar man kann das auch als so eine Art Gegensprechanlage bauen. Problem ist nur -> es dauert zu lange bis sich der Stream aufgebaut hat. Im Quick connect ca. 1 sec. sonst 3-4 sec. auch mehr bis die Bandbreite in den Switches reserviert ist und der Stream steht.

Also der Stream muss immer aufgebaut sein, das Gegensprech- Prinzip bzw. den bei bedarf aufzubauen funktioniert nicht. Was passiert wenn keine Bandbreite vorhanden ist ? Schlägt die Verbindung fehl.

Gewisse Eigenschaft lassen sich nur schwer umsetzen.

- Daisy Chain

- kein Netzteil bei den Clients

- Kommunikation unter den Clients

Wenn Digital dann ein eignendes Protokoll entwickeln das auf Layer 1 basiert oder Technologien wie AES50 nutzen die von sich aus gewisse Eigenschaften mitbringen. Das Produkt müsste dann Funktionen haben die ein herkömmliches Intercom nur schwer umsetzbar wären. Z.Bsp Handy Relais etc..

Leider hat das seine Ursachen. Bis zum 800er sind die Fader so auf 5V ohne Vorwiderstand. Löst ein defekter Fader einen Kurzschluss aus ist die Kiste Tot.

Ein 10K Widerstand hätte das Problem gelöst.

So etwas gibt es in anderen Foren schon. Wenn man einen Thread eröffnet wird beim eintippen des Titels nach begriffen gesucht. Technisch kann man den Aufwand begrenzen in dem man das auf Schlagwörter begrenzt. z.Bsp Lautsprecher , anschließen, Phase, usw.

Ich glaube kaum das in 1min 100 Beiträge aufgemacht werden deshalb ist die Belastung der Datenbank zu verkraften. Wenn man das auf Schlagwörter begrenzt und auf diese Schlagwörter kommt es an ob auch was Sinnvolles vorgeschlagen wird. Abkürzen kann man die Sache in dem man die Google Engine mitbenutzt. Aber wenn du bei google suchst durchsucht google dich . Leider hat man mit dem Umzug ziemlich viel zerstört so das die suche zu toten links führt. Das dauert etwas bis Tante google das wieder richtet.

Allerdings gibt es auch Nachteile.

Alte Thread werden Ellenbogen lang wenn sie immer wieder mit neuen Fragen beschrieben werden. Das kann und will keiner mehr lesen.

Es hält keinen von ab doch einen Thread zu eröffnen.