Beiträge von marcoboy

Zitat von wora

zunächst habe ich auch eine RME digiface Dante dazu gekauft, aber irgendwie hab ich die nicht zum laufen gekriegt.

Da muss ich mal etwa genau nachfragen. Ich habe jetzt ein RME digiface AVB und dies auf einem MAC M1 zum laufen zu bekommen war ebenfalls für Endanwender nicht zumutbar. Das hängt mit den Sicherheitsrichtlinien von Apple zusammen Kernel Module zu laden, nur mal grob umschrieben warum das so eine pleite war.

Der Rest war dann ein AVB-Controller der unter MAC M1 einfach hängenbleibt. Ohne dem ist das Interface nicht verwendbar... Ich äußer mich zum diese Hardware auch noch mal, da ich vom ganzen wenig überzeugt war.

Ähm die Hersteller erzählen dir aber was anderes. Das Problem ist jede Maschine hat so ihre eigene Temperatur. Zu heiß verbrennt das Fluid, zu kalt schmiert es oder läuft vorne raus.

Die Hersteller machen genau deswegen auch ein Geheimnis wie sie die Maschinen einstellen und zu Fluid her gibt es dazu kaum angaben.

Man könnte ja vergleichen.

Fazit: Es kann funktionieren, muss aber nicht und das merkt man erst nach Jahren des Betriebs.

Es gibt Unipolar und bipolar Typen und der Magnet ist ein Würfel und der hat sechs Seiten. ,,,

Man muss schon Erfahrung haben und dann klappt es auch mit technischen Dingen ganz gut ...

Mach doch einfach eins, baue die Sensor PCB aus. 5V dran und teste es aus auf welcher Seite der Hall Sensor schaltet. Machst du ein Punkt ran und klebst ihn in der Richtig ein. Kleiner Tip, das Werkzeug sollte nicht magnetisch sein.... Du musst schon schauen in welcher Richtung das Feld verläuft.

So ein Magnet hat Nord und Südpol… 🧐..

Das Thema mit dem Rad ist jenes das die meisten nicht an den Schrittmotor denken. Diese kann nur im Vollschritt oder halb schritt die Welle positionieren. Wenn man jetzt das Rad einfach so anschraubt kann es passieren das der Sensor immer übersprungen wird. Der Magnet kommt nie unter dem Sensor, er saust daran vorbei. Das Rad muss so auf der Welle positioniert werden das der Magnet im Schrittwinkel unter dem Sensor steht.

Beim Spiegel muss man aufpassen, es gab zwei Versionen. Die ältere hatte die Eigenschaft das die Halterung einfach durchbrach und der Spiegel nach unten viel. Bei der neuen wurde dies behoben....

Bei dem Werkzeug würde ich als Patient Angst bekommen .

Also ich wäre vorsichtig mit diesen Stufen. Je nach dem wo Sie gebraucht wurden ist der Ärger vorprogrammiert. Bei fast allen im der Zweistelligen Anzahl von Stufen die ich auf den Tisch hatte gab es Probleme mit der PCB, bzw. es war der Auslöser eines größeren Desasters. Weitere Probleme gerade der xx44 Serien das es die Benutzer wirklich ernst nahmen dann Sie an ihre Grenzen betrieben haben.

Ich habe auch noch eine S4004 hier liegen und würde diese trotz des Vertrauens meine Reparaturkünste nicht mehr auf Events einsetzen. In Anbetracht der Lage für Ersatzteile könnte es schwer sein diese bei defekten wieder zu reparieren. Zumal durch die Packungsdichte und SMD nicht so einfach .

Vorsicht beim lösen des Rades von der Achse! Diese muss im Schrittwinkel wieder montiert werden! Sonst wird der Hall Sensor niemals den Magneten erkennen....

Der Preis für den Bi-Metall ist ja heftig . Vielleicht sollte ich die Reste aus meiner Martin Zeit auch noch versilbern.

Welchen "Schnäppchen" habt ihr denn so zugegriffen ? Wie schon vermutet die Angebote haben keinen vom Hocker gehauen.

Mac2000: schon mal vom Sockel gemessen ob die Kabel i.o sind ?

pro918: schon möglich, Lötstellen der Hall PCB prüfen, schauen ob die Magneten noch da sind. Das weiß ich jetzt nicht mehr genau es kann sein da mehrere Hall Sensoren parallel sind. Die Ursache ist dann ein anderes Rad.

Kommt darauf an welche Handys man will. Gerade was Veranstaltungstechnik angeht gibt es keinen Grund etwas zu verschenken. Was jetzt angeboten wird sind keine Schnäppchen, in vielen fällen wurde der Preis künstlich erhöht oder man bezieht sich auf einen völlig überzogenen UVP. Bei Software ist ja kein Materialeinsatz nötig so kann z.Bsp Waves seine Zeug auch regelmäßig verschenken. Weil man dann spätestens nach einem Jahr am Haken hängt oder etwas kauft was man eigentlich nicht braucht.

Hardware bekommt man jedenfalls keine, nicht nur von waves..

So wirklich viel gibt es nicht zu verschenken. Die Lager sind leer und bis auf Software ist kaum was zu erwarten.

Du bekommst diese nicht einmal von der PCB und beim auflöten ist die Optik hin. Die PCBs sind alle aus ALU und ohne die richtige Technik geht da gar nichts. Das Problem ist das diese mit der Betriebsdauer dunkler werden. Man sieht sofort den unterschied... Wenn der Hersteller eine solches LED Modul als Ersatzteil bereitstellt mag man den Kopf retten können. Aber das ist vom Preis nach 5 Jahren nicht wirtschaftlich tragbar.

Clay Paky Alpha Spot lag so um die 5000€ pro Kopf... ...

http://www.foeoen.de/katalog/9.html wenn du den nachbaust werde ich sauer...

Leider lässt sich die LED Quelle nicht Reparieren oder gegen was anderes ersetzen. Wenn wir jetzt von defekten im Diodenarray ausgehen ist da Feierabend. Zwar hat ein renommierter Hersteller Ersatz aber das Problem kommt dann wenn die anderen Eimer schon 5 Jahre alt sind. Defekte an der LED Quelle sind meist auch der Totalschaden am Gerät und die aus Chinesischer Fertigung gehen oft kaputt oder werden massiv dunkler. Also auch kaputt..

Man kann so sagen das du alle 3-5 Jahre neue Eimer brauchst. Früher hast du nach 2000h einen neuer Brenner rein geschraubt, die Optik gereinigt und dann war der Output wieder vorhanden.

Klar hat es 250er mit CMY und Zoom gegeben, auch mit E-Ballast. Nur war das eine Nobelmarke .

Da ist ganz normale PC Hardware drin. Anbetracht des Alters lohnt sich selbst Hand anzulegen. Ich glaube auch kaum das du zum akzeptablen Preis den Touch bekommen wirst, wenn dieser überhaupt noch lieferbar ist. Mit der Mouse lohnt sich auch das Ding mal zu zerlegen…

Nun du musst ja auch die Daten zum Wandler übertragen. Die Betrachtung sieht einfach aus ist aber dann doch nicht so einfach.

MCLK muss zwingend von der CPU Hardware erzeugt werden und synchron mit der PTP sein. Warum?

Die Daten müssen am Wandler zum Zeitpunkt x vorliegen, lesen/schreibend ist da egal.

Im Stream ist eine Präsentationstime vereinbart. Wann die Daten am Ausgang erscheinen und diese Zeit ist von der PTP abgeleitet. Stimmt diese Zeit nicht läuft der Buffer über oder leer. Da ja der Talker die Daten immer weiter sendet, zur PTP Zeit. Bist du zu schnell sind die Daten gar nicht vorhanden, zu langsam läuft das Glas über und die Daten sind verloren.

Einfacher ist es ohne Hardware. Empfangen ist kein Problem und mitschneiden. Senden musst die Hardware in der Lage sein die Pakete zu stempeln und synchron mit der PTP sein. So kritisch ist das ganze ja auch nicht, 2ms ist eine menge zeit die man hat, da kann man große Buffer bauen.

2 Channels In/Output mit einem ARM halte ich für realisierbar. Wenn die PTP/PHY und i2s vorhanden sind. Man braucht aber QOS was zuverlässig funktioniert und das lässt sich nicht auf dem ARM mit einem Core machen. Da muss man dann eine PHY nehmen oder einen Switch IC der das kann. Sonst kann man mit dem 1722.1 den Stream flach legen.

Im übrigen ein Mangel in den alten XMOS Geräten. Der Core war mit dem Stream schon zu sehr ausgelastet das dieser 1722.1 Pakete ignorierte. Dieser hatte sie zurückstellen müssen und innerhalb von 250ms ausliefern. Alternativ antworten und sich mehr zeit erbitten.

In erster Linie ging es ja hier im einen Controller. Das man da so tief einsteigt das man auch in der Lage ist Geräte zu bauen fällt nebenbei ab.

Das mit dem CM4 war eine angedachte Nebenbaustelle in Verbindung mit dem Projekt. Es ging darum in Streams rein zu hören und PTP Dinge anzuzeigen. Auch die Hardware als Produkt zu verwenden -> ist ja sowie so nicht lieferbar.

Das mit den rein hören ist an sich leicht machbar, man schneidet die Pakete einfach mit, die Zeitbasis ist erst mal Wurst . Du musst aber erst mal die Switch und die AVB Geräte dazu bringen dir einen Stream zu schicken.

Beim CM4 ist genau das passiert was ich befürchtet hatte , die Entwicklung des PTP Treiber ist gestoppt. Ich vermute einmal weil die PHY von Broadcom nicht richtig funktioniert. Die PHY stempelt die Pakete und der Kernel unterstützt dies auch. Knackpunkt ist der Treiber, der muss dies an den Kernel übergeben.

Der Controller ist fast kein Controller mehr, er ist in der Lage sich selbst als AVB Gerät im Netzwerk zu publizieren. Das ist ja die Grundvoraussetzung um einen Stream zu erhalten. Was man machen kann und das ist eine weitere Baustelle. Die Descriptoren per JSON einlesen und Callbacks zur Verfügung zu stellen. So ließe sich auch ein Endgerät steuern welches auf dem System läuft. Dazu muss man aber die Pakete im Kernel anhand des CD Bits filtern, dazu lädt man ASM Code in den Kernel.

AVB Geräte mit ARM sind so eine Sache. Dazu braucht man mehrerer Cores auf dem man Zeitkritische Dinge aufteilt. Flaschenhals ist die Schnittstelle der PHY und Interne Schnittstellen . 1Gbit/s zu verarbeiten geht eigentlich nur mit einem FPGA. Der XMOS macht bei 44Mbit/s zu, also mehr wie 32ch 48KHZ geht nicht, trotz 1Gbit PHY. Das XMOS Zeug würde ich auch nicht verwenden wollen, die kümmern sich um ihren Code nicht und dieser ist seltsam zusammengenagelt.

Das Projekt ist ziemlichen Verwerfungen ausgesetzt. Einige Dinge fasse ich zum dritten mal an, da ich keinen Berater hatte die mich davon abgehalten hätten. Jetzt wird mein gebastelter JSON Generator ausgetauscht. Das bringt an andere Stelle wieder Vorschritte und der Code kann entschlackt werden. Tja wo soll es hingehen, zum TSN Controller der alle Dinge im Standard unterstützt. Macht er ja schon, also einziger mit Video und Sensor Units etc.

An dem eigentlich AVB Core wurde bis auf Kleinigkeiten kaum etwas gemacht. Die größte Zeit frisst das Userinterface mit HTTP/REST Schnittstelle. Da ich mich von Anfang an gegen eine Grafische Oberfläche verwehrt habe und konsequent auf HTTP setzte hat das Projekt gegenüber Mitbewerbern voreile. Sie übernehmen ja auch ein paar Dinge.... Mir fehlt das 50 Man starke Entwickler Team . Das ich den Code noch nicht veröffentlicht habe hat genau jene gründe. Ich muss mir über die Auswirkungen auf mögliche Anwender keine Gedanken machen...

Es kommt sogar noch schlimmer, mit TPM 2.0. Das habe ich unter Linux durch. Es ließ sich unter den proprietären Treiber kein externer Bildschirm anschließen. Der Monitor wurde erkannt aber kein Output. Der freie Treiber lieferte zwar ein Bild, aber man konnte keine Fenster anzeigen. Wenn man versucht hatte was auf den Bereich zu schieben wurde es nicht angezeigt. Der Linux Treiber war nicht signiert und die Hardware sagte dann "unsicher". Die Ausgabe wurde durch die Hardware blockiert.

Security boot mode spielen da eine Tragende Rolle. Die Reise geht dann dahin sobald du eine Software aufspielst die nicht signiert ist wird der Bildschirm schwarz. Die Zertifikate kann man auch widerrufenen und ab win11 hast du keine Möglichkeit mehr an TPM 2.0 vorbei zukommen. Sobald du dann etwas oben hast ohne Zertifikat ist der Bildschirm dunkel.

Sobald du etwas änderst an der Hard/Software muss dies gegen über Bios signieren werden.

Das kann noch lustig werden wenn mal eben einen Laptop von Herrn xyz ansteckt und die Übertragungsstrecke den Betrieb einstellt.

Es kann nicht schaden, auch bei 2G Veranstaltungen Mitarbeitern das tragen von Masken vorzuschreiben. Kann man machen, würde ich sogar empfehlen.

Warum? Ich habe an mehren 2G Veranstaltungen teilgenommen und Infektionen die auf solchen Veranstaltungen stattfinden lassen sich durch die Gesundheitsämter nicht mehr nachvollziehen. Im Grunde haben wir jene Situation wie vor einem Jahr. Man lässt es einfach laufen um im Dezember die Notbremse zu ziehen. Der einzige Unterschied liegt nur darin das geimpfte Menschen nicht so häufig in den Krankenhäusern laden. Erschreckend sind die zahlen unter jungen Menschen, in einigen Landkreisen und Städten ist das Sieben-Tage-Inzidenz bei 500 oder gar 1000.

Das sagt ich immer das tragen vom Masken wird beim Publikum nicht akzeptiert noch ist es durchsetzbar.