Seit 2017 gilt ein generelles Überflugverbot von Menschenansammlungen. Das ist zweifelsfrei ohne Ausnahmen verboten. Behörden werden dies vermutlich auf dieser Rechtslage immer ablehnen. Genau das ja der Punkt, wenn es über solche Überflüge bei Veranstaltungen geht. Das hatte durch aus seinen Reiz, ist aber durch die Gesetzgebung fast unmöglich geworden. In der Verordnung steht "seitlicher Sichtabstand von 100m"...
Außer die Behörde benötigt solche Überflüge zur Erfüllung ihrer Aufgaben.
Es ist schlicht verboten über Menschenansammlungen zu fliegen und es ist ein seitlicher Sichtabstand von 100m einzuhalten. Auf Festivals etc. wird dieses generelle Verbot immer wieder ignoriert.
Moin,
wer will hier debuggen? Und findest Du den Passus mit dem Chinesen nicht ein wenig rassistisch?
skippa
Nö, die haben das Ding mit Original Firmware massiv nachgebaut. Eben mit solchen HEX Editoren die Strings ausgetauscht....
Was willst du den Code Debuggen ? Wozu ? Siehst du aus wie ein Chinese ?
Das Reichelt Teil funktioniert natürlich...
Ich habe ein BX48 in der Werkstatt, für den Fall das die Eproms ärger machen oder die Firmware zu alt ist. Backup ist nicht nötig, den HEX Code bekommt man , wenn man kein Schlitzohr ist ganz legal.
Wer misst misst Mist ?..
Du musst das Signal schon mit 110Ohm einkoppeln. Das geht mit einem AES/EBU Trafo oder einem Bus Treiber der auch korrekt beschalten ist.
Am Ausgang Tritt genau das gleiche Problem auf. Die 110Ohm sind aber gegenüber des Eingangswiderstand vom Ozzi weit weg. Der muss Massefrei sein, wie du das auch immer anstellst.
der xmos hat noch einen entscheiden BUG der mir auffiel, er verzählt sich im available_index. Womit mein Controller sich veranlasst fühlt, das entity neu einzulesen. Es könnte ja gebootet haben..
Ich bin gerade damit das Problem mit der Datenbank in angriff zu nehmen 
.
Meine Auswahl viel auf http://whitedb.org/ womit durch die GPLV3 in unsicheres Fahrwasser begebe 
.. Deswegen habe ich beschlossen den Reiter nicht ausschließlich auf dieses Pferd zu setzen. Was bedeutet das der alte Code basierend auf einen File erhalten bleibt und die Grundsätzlichen Funktionen nachgeführt werden. So kann man sich später entscheiden oder den Code austauschen.
So eine In-Memory-Datenbank hat viele Vorteile und die ersten Test sehen vielversprechend aus...
Warum jetzt doch hat damit zu tun das ich den Mechanismus "unsolicited notification" Implementieren wollte.
Damit kann ich ein Controller beim Entity registrieren und erhält die Antworten vom Kommandos die Änderungen auslösen ebenfalls. Z.Bsp wenn ändert man die Samplerate, oder einen Namen etc.
Ich wollte die Daten dann im zugehörigen Descriptor Aktualisieren und nicht wie andere alle Descriptoren neu einlesen 
. Genau ist ja auch nicht der Sinn der Kommandos aber einige haben sich das einfach gemacht, z.Bsp Riedel AVB Manager.
Andere haben da ganz andere Ideen http://grouper.ieee.org/groups/1722/1/…tion%20time.pdf
Genau das bitte nicht und schon gar nicht Pakete teilen wenn sie dann zu groß sind ! Es gibt keine Dynamischen Infos, es sind Daten die zu den Descriptoren gehören bzw. aus diesen ihren Ursprung haben.
Der Controller muss die Daten in den Descriptoren nach führen ohne diese neu zu lesen, alles andere Erzeugt jedes mal eine hohes Trafic aufkommen, welches die Warteschlange überfordert.
Genau hierzu braucht man eine Datenbank in dem man die Einträge heraus sucht und aktualisiert und die Anfragen der Clients erfolgen kann aus der db heraus und nicht aus den entitys.
Das haben wir aber auch beim THW machen müssen... Ging auch nicht anderes es war keinen Klar zu machen das für 10min das Licht ausgeht. Die Gefahr das jemand zu schaden kommt, weil er wo herein fällt war auch viel zu groß. Also hat man versucht die Dinger im Laufenden Betrieb zu betanken ohne zu kleckern.
Abhilfe gab es nur als man sich Technik anschaffte die unter Vollast min. 8h durchlief oder sich extern sicher betanken ließ. Gerade den Ossis hatte man den alten Schrott überlassen.
Das Licht ging also nur aus wenn jemand vergessen hatte das Ding zu Tanken oder es wurde geklaut. Das kam auch vor das dass Kabel nur noch im Dreck lag...
Der Fehler bei diesen Umzügen ist besteht darin das die Aggregate teilweise verbaut werden. Oder auf er Abenteuerlicher Weise der Auspuff verlegt wird, zu Nahe an Brennbaren Materialien z.Bsp. und da fliegt allerhand durch den Waagen. Rucksäcke etc. landen auch schon mal hinter dem Endstufen Rack 
...
Vorsicht mit dem USB Adaptern es gibt einige die Funktionieren oder auch nicht. Das hängt mit dem Timing zusammen. Ich habe hier in der Werkstatt mal mit segger J-link mit einer USB Verlängerung probiert und es hat nicht funktioniert. Mit HID Devices Bsp USB Sticks,Keyboard etc. schon. So war die Sache unbrauchbar, ärgerlich bei 70€ kosten.
Was geht ist RS232 auf RS422/485 umsetzen, dann geht das auch über das Multicore oder CAT5 je nach Baudrate problemlos.
Die ganze Dinge die RS232 auf Ethernet umsetzen sind ähnlich problematisch, wegen dem Timing. Das Protokoll ist bei RS232 nicht spezifiziert. Gerade die in den alten Geräten vorhanden Mikrocontroller haben so ihre Probleme mit unsauberen Timing welches von solchen Adaptern kommt. Heutige 8 bitter sampeln die UART und haben damit er weniger ein Problem. Die SIO vom Z80 schon...
das wäre natürlich ein Unding, bei Avid ist es so das man den Stageboxen zwar Namen geben kann, diese sind aber nur oberflächlich, selbst wenn ich als Beispiel Stage1 und Stage2 habe, und die Namen tausche, also 1 gegen zwei kommen die doch wieder an die alte Stelle im System.
Scheint also zumindest dort richtig gemacht worden zu sein.
Du änderst ja die entity ID nicht 
die ist fix und pro Gerät nur einmal vergeben. Außer sie wird dynamisch erzeugt. Denn kann das Gerät nach dem booten eine andere entity ID bekommen. Vorher muss aber das entity sicherstellen das die ID nicht vergeben ist. Hierzu müsste es erst mal ein ADP entity_disccover senden worauf alle entitys mit einen ADP entity_available antworten.
Kurz um entity_disccover antwortet nur Apple... XMOS nicht -> das werde ich aber noch fixen :). Hier muss man ein viertel der valid_time abwarten bis das entity die entity_available messages versendet.
Der Controller macht beim starten genau das gleiche, er sendet ein ADP entity_disccover womit sich alle entity melden sollten und somit sofort in der liste erscheinen. Die valid_time kann von 2-62 sec vom entity vorgegeben werden. Es dauert also maximal 62 Sekunden bis ein Entity in den Timeout läuft.
Ein Entity kann sich aber auch abmelden wenn sich der Controller beendet sendet dieser eine entity_departs messages.
Nunja das mit dem dynamischen EUIs hat seinen Hintergrund das man Geräten einfachen Zugang zum AVB Netzwerk ermöglichen möchte. Feste EUIs müssen Formal Registriert sein. Jeder Hersteller bekommt seinen Bereich zugewiesen. Das ist mit Aufwand und mit kosten verbunden.
Bei DMX RDM ist die Zuweisung kostenlos, auch ich habe eine eigene UID zugewiesen bekommen und kann damit offiziell im RDM Netzwerk teilnehmen .
Die bekannten Schlitzaugen kopieren auch UIDs und MAC Adressen, da diesen der Aufwand sie formal zu Registrieren zu hoch erscheint. So kommt es dann mal vor das Geräte mit deinen Adressen auftauchen.
Das Problem mit dem dynamischen Geräten ist er das Controller damit umgehen müssen das sie plötzlich mit Lehmann anstatt mit Schulze sprechen.
Per MAAP werden ja MAC Adressen für den Stream schon dynamisch vergeben. Der Pool umfasst 255 Adressen. Diese Adressen sind in der Switch als Multicast registriert. Somit ist die Anzahl der Streams in einer AVB Netzwerk auf 255 Streams begrenzt.
Ich muss nochmal auf die Frage des Entity Identfier eingehen.
Nun hat man sich im Standard 2016 ausgedacht das diese auch dynamisch vergeben werden können. So wie das bei USB üblich ist. Das bedeutet sobald das Gerät bootet hat es eine andere UID. "schulze tauscht mit Lehmann, Lehmann mit Maier..
Dynamische EUIs kann man anhand der Bits erkennen https://de.wikipedia.org/wiki/EUI-64.
Die Geräte müssen dabei sicherstellen das keine EUI doppelt vergeben wird.
Für den Controller bedeutet das mitzubekommen wenn ein Gerät bootet um den Datenbestand neu aufzubauen. (Bei mir erfüllt ).
Für den Anwender muss klar sein das diese Daten nicht sicher sind und ich hoffe das kein Hersteller auf die Idee kommt Stageboxen mit dynamischen EUIs herzustellen.
So es hat sich was getan...
- Rest API wurde komplett überarbeitet
- die JSON auch
- die API wurde dokumentiert damit man auch damit was anfangen kann
- der controller macht sich jetzt auch per ADP discovery im AVB Netztwerk bekannt
- AECP AEM kann er auch und es lässt sich der Descriptor entity anrufen, dann ist auch ersichtlich wie das Schwein heißt, mit anderen Controller lässt dann auch ein Namen etc zuweisen (noch nicht implementiert )
- Bugs beseitigt und Verbesserung umgesetzt..
Wer schauen will https://insomnia.rest/ den Workspace im ZIP File importieren. Unter den Reiter Doc sieht man auch was zurückkommt. Um es auszuprobieren benötigt man den Controller . Wer es wirklich probieren möchte kann die Einzelheiten mit mir abklären.
Rechtschreibfehler und unklare Äußerungen sind inkl. 
. Es fehlen noch die HATEOAS links.. https://en.wikipedia.org/wiki/HATEOAS . Noch muss man die Struktur des Entitys kennen oder sich durch arbeiten.
Nimm doch das Format der Aufnahme z.Bsp 192khz. Wie das genau abläuft bei WDM bzw. Asio kann ich nicht sagen, da musste den Tomy (satlive) fragen. Der hat Erfahrung mit solchen Geschichten, auch weniger schöne.
Gar nicht, VIA wird "vermutlich" ohne PTP IEEE1588 arbeiten. Es ist ein asynchrones System mit Buffern und einen RTP Stream. (vermutlich) ich habe mich damit nicht befasst....
Solche Lösungen wie VIA gab es ja davor auch schon, nur eben nicht mit Windows... Es wird nur die internen Clock benutzt und somit aus dem Buffer gelesen. Unter USB ist dies allgemein schwierig, die Kunst ist es einen overflow oder underflow des Buffer zu vermeiden. Schau dir mal das Jittern bei USB Soundkarten an....
eben doch den die samlingrate wird teil des Stream Formates sein. Wenn du ein File mit 96khz abspielst und es auf einen Interface mit 48khz ausgibst macht üblicherweise der Player eine SRC. Der Empfänger kann nur das nehmen was ankommt. Nehmen wir mal er trifft auf eine Soundkarte die nur 48khz kann, das muss dieser die SRC machen oder es klappt ein Fenster auf "ich kann nicht"
Man sollte sich darüber eigentlich eine Gedanken machen müssen.
Ich mir das auch mal mit dem MILAN angeschaut. Kurz gefasst sind es Absprachen welche Funktionen ein Gerät unterstützten muss. Ein paar Kommandos wurde die Response um Felder erweitert, was ich unschön finde. Da dies an einer nicht vorgesehenen Stelle passiert. Wenn die IEEE das Protokoll erweitert gibt es den Salat. Beim ACMP haben sie die Funktionen umbenannte und die Timeouts auf 200ms festgelegt. AVB Geräte haben hier z.Bsp beim TX_CONNECT 3s Zeit. Ob das ausreicht um die Bandbreite mit SRP über 7 Switches zu reservieren !? Da zweifel ich die 200ms arg an...
Man hat sich auch auf ein einfaches Streamformat geeinigt, AM824 ist doch zu komplex.
Außerdem wurde ein Vendor basierendes Protokoll hinzu gefügt, mit dem Kommando get_milan_info.
Alles halb sie schlimm, wenn ich noch heraus bekommen wie man milan Geräte sicher erkennt.
https://www.l-acoustics.com/en/hotnews/l-a…s10-avb-switch/
mal was neues, mich würde interessieren ob hier Marvell oder Microchip zum Einsatz kam.
Nö nimmt die Werte welche das Interface zur Verfügung stellt.
Ich auch das ist keine Originale Weiche..
