Beiträge von marcoboy

So meine Herrn und Damen.. was bisher geschah..

Den Code auf Speicherleeks untersucht und Problemstellen beseitigt.

Dann kam ich auf die Idee, den Webserver in den Controller zu integrieren. Vorher lief das ja über einen externen Webserver mit CGI Modul. Die Kommunikation zwischen dem Modul und Controller funktionierte mit unix sockets.

Es funktionierte gut, wäre aber nur auf Unix Systemen lauffähig gewesen und von externen Diensten abhängig.

Kurzum der Entschluss mir eine HTTPD Bibliothek zu suchen und sie in das Projekt einzubinden. Ganz einfach diese Aussage... Es gingen zwei Wochen ins Land um überhaupt die Probleme zu lösen die sich plötzlich auftaten. Das fing schon mal damit an das die das Json in der Art nicht mehr erzeugen ließ.

Die dann zum Einsatz gebrachte Json Bibliothek brauchte dann für eine Response 65MB speicher.. Ohje .. Nein den Käse kann man nicht verwenden.

Drei Toiletten Sitzungen + einen Wutausbruch in 3 weiteren Tagen braucht die Lösung des Problem.. Ohne den Code der die Dokumente erzeugt über den Haufen zu werfen.

In weiteren 3 Tagen schlug ich mich damit herum zu eruieren warum sich die Bibliothek bei falschen GET Anfragen mit Body immer aufhing. Wie man das umgeht bekam ich dann auch heraus.

Nun müssen die request auf den neuen Code portiert werden...

Baustelle HTTPD bleibt, Zugriffskontrolle, File API, usw....

An den eigentlichen Funktionalitäten ergab sich nichts.. Dafür startet man den Controller und er ist auf einen Port erreichbar..

Zwischendurch flog der alte Dell auseinander, Mutti brachte ihr Breitbandinternet mit 1 Woche Totalausfall.

Ihr merkt es ist einiges passiert...

Das Problem an der Sache ist das ungeeignete Kabel keinen definierten Wellenwiderstand hat. Da dessen Aufbau dies nicht zulässt.

Ohne RDM funktioniert das irgendwie doch halbwegs über gewisse Strecken. Mit RDM drauf gibt es dann ein Problem, gerade wenn die Leitung offen ist, das ist bedingt das der Master die Sende Richtung umschaltet und in dem Moment ist alles Hochohmig. Das undefinierte Verhalten führt dann dazu das der Master denkt es würden ihm Geräte antworten und den Bereich der UIDs immer weiter einschränkt. Am ende wird kein Gerät gefunden.

Ähnliches passiert wenn die Leitung nicht angepasst wurde.. Das ungültig Datenpaket deutet der Master als würden zwei Geräte antworten und versucht das was er gerade bearbeitet zu muten.

Fazit mit RDM drauf ist eine ordentliche AES/EBU Leitung unabdingbar..

Was wurde denn verbaut !?

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..

In ein besseres Netzteil investieren -> weniger rauschen etc. allerdings gleich vorweg die Mainboard Soundkarten sind meist immer Problematisch -> sehr geringer Preis ;). Einfache und billige Filter etc..

RME hat schöne Soundkarten

Auch ich dachte im Fernsehen ;). Wäre aber einfach..

Tja und der Automarkt benutzt sensors, was kein Controller außer meiner unterstützt..

Ich übrigen bin ich gerade dabei den externen HTTP Server mit dem fastCGI Modul über Board zu werfen.

"Hallo" auf dem Port 8080 geht schon mal ..

Zitat von Marian Humann

Die Kameraübertragung wird afaik immer analog ausgeführt, aus Latenzgründen.

Hust... https://de.wikipedia.org/wiki/Serial_Digital_Interface

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 .. 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 ..

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.

Man kann eine Marke auch kaputt optimieren.. Siehe was mit Martin Professional passierte...

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...