Beiträge von marcoboy

    A: wir reden über Hardware Geräusche, kommt bei billigen Drosseln und Filtern schon mal vor.


    B: wir reden über mittelmäßig Design der Spannungsversorgung vom Mainboard.


    C: wir reden über billige Netzteile, das trifft auf alles unter <200€ zu..


    Wenn B+C zusammentreffen schwimmt so ziemlich alles mit, Sound ist er eine herzlose Beigabe vom Mainboard und für den Otto normal User reicht es immer aus...


    Auch billige externe Soundkarten machen dann dabei mit, wenn ihr Konstrukteur die USB Versorgung nicht gut abblockt.


    Ganz fies sind Störungen vom Ethernet, verursacht durch ein schlechtes Layout..

    Nunja aber Dante hat es nun auch geschafft Video zu übertragen.. Genau an dem Punkt klinken sich bekannte AVB Controller aus. Weder Sensor noch Video werden unterstützt... Mein Projekt kann das :D.. Allerdings habe ich noch kein Gerät in die Finder bekommen das dies tatsächlich könnte. Gut Sensor wird es im Auto mit AVB wohl oder über geben. Aber soweit ich weiß ist der CAN Bus wohl da noch führend..

    Das Problem was sich mir in den Weg stellt sind A: ein Haufen Geräte die nicht das machen was sie sollten, auch Controller wenn ins Detail geht... B: sehr viele Baustellen, HTML,REST,Datenbank, HTTP usw...


    C: das eine Technologie wie HTTP nicht dazu gedacht ist.. Besonders blöd wird es bei der Notification.. Es wo sich der Controller im Gerät registriert und bei Änderungen Benachrichtigt wird. Per HTTP müsste man immer pollen -> also Abfragen, Abfragen.. es sei denn man verlässt die REST API und hält die Verbindung offen...


    HTTP und Javascript hat noch weitere Stolperfallen, die Implementierung ist Browser abhängig. Nicht immer passiert genau das was man eigentlich wollte. Die Baustelle UI per HTTP und Javascript ist riesig... und das Status Problem ist noch nicht gelöst...


    Deswegen jetzt der Gedanke das Projekt zu splitten...


    Den Controller als Dienst und als Brücke zum AVB Netzwerk. Optional speichern der Daten in einer Datenbank. Das UI könnte dann per TCP/IP und DB Treiber sich die Daten aus der Datenbank holen... genau so das fastCGI Modul -> HTTP Schnittstelle.


    Oder man macht es dem IPC Socket einen richtigen Socket... Null Problem und bindet dann das UI mit GTK oder QT gebaut an...


    Ich weiß es nicht ....;(.. Fakt ist eins das eine Software die sich auf MAC,PC Installieren lässt eine bessere Verbreitung findet .. und leider bekommt man gerade unter Win nur mit einen speziellen Treiber Zugriff auf das Layer2. Dieser ist der Gau was die Sicherheit eines System betrifft.


    Und es geht dann genau der reiz der offenen Schnittstelle verloren. Mit der Rest API kann man den Controller sogar per Arduino steuern... Hauptsache das Gerät kann HTTP... Wenn sich Hersteller Scripte bauen können sie ihre Geräte testen.. Alexa,MQTT etc.. geht alles...


    Man kann per Connect sogar wie vorgesehen die stream_vlan_id und flags setzten..

    Ich hänge mal die Ausgabe der Konsole mit ran. Da kann man schön sehen wie das ganze abläuft.


    Das ganze läuft als Multicast ab, das bedeutet andere Controller können den Verbindungsaufbau mit verfolgen und dementsprechend ihre Daten aktualisieren.


    Der Controller sendet ein connect_rx an den Listener(Emfänger Lautsprecher z.Bsp) dieser sendet ein connect_tx an den talker (sender Mikrofon z.Bsp ) dieser erledigt alles was für den Stream nötig ist und sendet dann ein connect_tx_response an den Listener. Der darauf dann ein connect_rx_response an den Controller sendet.


    Im Hintergrund passiert noch deutlich mehr, Reservierung der Bandbreite, Bildung des Vlan und MAAP -> finden der MAC Adresse für den Stream.

    Tadaa der controller kann ACMP -> Geräte verbinden... Allerdings muss ich jetzt mal schauen wie man diese Information dauerhaft so aufbereitet das sich daraus eine Matrix bilden lässt. Ich sprach ja von Datenbank..


    Jetzt bin ich aber doch auf dem Pfad, eine Oberfläche zu bauen... QT scheidet aufgrund der Lizenz aus.. Bleibt nur noch GTK(in C geschrieben).. per Option kann man dann die Oberfläche mit einbauen bzw. die REST API ausbauen ;) . Dem Core ist es Wurst, zum Glück habe ich das vorher schon gut getrennt.


    Bleibt nur noch das Datenhaltungs- Problem. Das gilt es Plattform übergreifend zu lösen...


    Auf dem Bild sieht man wie man per Post eine Ressource anlegt, normalerweise sollte dann ein Objekt zurückgeliefert werden wo der Client den Status abfragen kann -> wir erinnern uns Rest ist Statuslos. Genau da haben wir das nächste Problem das wir lösen müssen ..


    per Delete löscht man die Ressource wieder...

    Man nehme einen 8ch Player und einen Arduino, wenn gewünscht ist ein DMX Pult. http://www.waveplayer-systems.de/ Fragen ?


    Per RS485 lassen sich 32 Player a 8 Kanäle steuern... Wenn du willst ich habe ein DMX Interface für den Player mal programmiert. Damit lässt sich der Player steuern und auch jeder Kanal in seine Lautstärke per DMX steuern...


    Das steuern per serieller Schnittstelle ist für einige nicht einfach da der Player in seinen Protokoll ein CRC8 Checksumme mit sich trägt. Da steigen die meisten Arduino User aus ^^


    Sieht dann so aus...

    Du kennst mein Problem mit der Deutschen Sprache *lach* das rutsch mir immer noch so raus.. Gott sei Dank wird meine Arbeit nicht nach meinen Sprachgebrauch bewertet...

    Allgemein ist das wilde umstöpseln wie im Audio Bereich üblich mit Netzwerkkomponenten keine gute Idee. Bis eine Switch wirklich merkt das die MAC auf einen anderen Port ist dauert es schon ein mal..


    Hinzu kommen ja die Mechanismen, Bandbreiten Reservierung, Vlan, PTP usw..

    Naja es wird der Präsent Timer verändert, denn der Router könnte ja ausfallen.. Der steht Default auf 125s und default 10s muss der Client auf den Query antworten.


    Heißt wenn man den Port einfach so umstöpselt löst das ewt. nervöse Blicke aus erst recht wenn man in der Panik sein Entscheidung revidiert :D..

    Will man das nicht spendet man für AVB, da sorgen die Clients dafür das die Switch sicherstellt das alles für den Stream veranlasst wird. Vlan,Bandbreite usw...

    Ob sich dann einer Denken kann in welchen Zusammenhang der Aufkleber steht ?


    A: du schaltest es ein -> die Switch gibt den Multicast Stream nicht auf den Port aus wenn das Gerät nicht auf den Query antwortet.


    B: da machst IGMP aus, der Multicast Stream wird auf allen Ports ausgegeben...


    B: kann einige Geräte überfordern....


    Ich kann dir nur raten Ports zu schaffen von dem an dem jegliche Multicast Stream, PTP etc. blockiert werden. Wenn du dahinter noch einen einfachen Access Point betreibst drücken dir diese Pakete ziemlich sicher das Wlan zu.

    Ich dachte du bist Lernfähig :/... Ohne die zu Dinge verstehen, wird es schwierig daraus entstehenden Probleme abzuleiten.


    Natürlich aktiviert man das in der Switch. Empfänger müssen den Standard aber unterstützen und auf die Query antworten. Sonst gibt die Switch den Stream nicht an diesem Port aus.


    So pauschal kann man das nicht sagen... Umzu vermeiden das Multicast Pakete auf Ports ausgeben werden gibt es weitere Maßnahmen.. Auch bei Dante Geräten gab es mal einen Controller Port wo solche Pakete blockiert wurden.

    IGMP Snooping Querier sendet die switch query anfragen auf ihren Ports. Um zu testen ob sich an dessen Ports Geräte befinden die sich für den Multicast Stream interessieren.


    Sie muss also nicht mehr schnüffeln...

    Dumme Switches machen genau das -> sie geben die Mutlicast Trafic auf alle Ports aus. Genau das Problem tritt auf wenn man einen AVB Stream über eine Normale Switch schickt. Die MACs sind Multicast Adressen und die Switch macht genau das -> auf alle Ports Ausgeben..

    Schnüffeln ^^. Es gibt ein Problem wenn du einen Mulicast Steam in den Heimnetz anschauen willst. Dein Router hat dann ein Problem die MACs zu zuordnen. Nach außen sieht das Netzwerk die MAC vom Router.


    Sie belauschen IGMP Trafic und erfahren wann ein Host einer Gruppe beitritt oder verlässt. So kann er sein MAC Table aktualisieren und weiß wo die Trafic hin muss. Was im schlimmsten Fall passiert ist das die Trafic an alle Ports ausgegeben wird...


    Wenn du es nicht aktivierst passiert eben der Schlimmste Fall, es wird an alle Ports ausgegeben. Damit belastet du die Geräte unnötig mit Trafic. TCP/IP Stacks mit Mikrocontrollern lassen sich so leicht lahmlegen, da sie der Trafic nicht gewachsen sind.

    Der sender weiß erst mal nicht wer seine Pakete empfängt, die Verteilung übernimmt die Switch. Die Clients teilen der Switch mit welche Pakete sie aus welcher Gruppe haben will. Bei der Version 1 kann sich dieser nicht ein mal abmelden -> Stecker ziehen :/..


    Wo war jetzt die Frage ? Angst das die Pakete ins Wlan geraten ?