AVB in der Theorie super aber die Praxis ist eher bescheiden

Jahresabschluss:

Wie weit ist er denn !?

kurz davor den stand auf IEEE1722.1-2021/D13 zu heben. Meine Nase hängt mal wieder weit vorne. Was war passiert? Ich kam auf die Idee meinen alten Mac auf macOS Monterey zu heben. Erstaunlich das dies mit einem Gerät von Mitte 2015 noch funktionierte. Jedenfalls hat sich am AVB-Stack von Apple erheblich etwas bewegt. Dieser unterstützt jetzt auch AAF und CRF Streams. Ohha... Da tauchten plötzlich neue Descriptoren auf, TIMING,PTP_INSTANCE und PTP_PORT. Es ging nicht anderes als mich auch von den Grundlagen auf den neusten Stand zu bringen. Denn Mitte 2022 wird es eine neue IEEE1722.1 geben die erheblich mehr Kommandos am Thema PTP mit bringt. Auch der IEEE1722-2016 wurde erheblich erweitert. Später sicherlich mehr..

Die IEEE1722.1-2021/D13 ist in den Descriptoren umgesetzt und weil ich schon mal dabei war habe ich den letzten Gurkencode von 2018 gleich mit umgedreht. Sowie den nächsten Schritt vorbereitet..

Schreiben kann man diese auch und zwar per JSON, man schickt das Dokument auf einfach zurück. Der einzige Controller der WRITE_DESCRIPTOR überhaupt unterstützt, das vollständig.

Die IEEE1722.1-2021/D13 hat auch endlich ein Kommando wo man mehre Kommandos zusammenfasst in einer Anfrage. Da bin ich jetzt dran, Kommandos die auf Parameter beruhen JSON basierend auszulösen. Keine Webformulare mehr, wer was ändern will manipuliert das JSON und schickt es zurück. Was man ändern kann -> siehe API.

Neue Hardware ist auch eingetroffen -> RME digiface AVB. Auch hier in einem extra Thread ein paar Worte..

So Guten Rutsch...

Huhu ..

Lebt das Projekt noch !?

Aber sicher und es hat sich einiges getan..

• Alle Methoden sind jetzt JSON basierend -> keine Formulare mehr
• neue Flow API -> deutlich besser
• alle Kommandos aus der IEEE1722.1 2021-D13 implementiert -> ein Haufen Arbeit!
• MILAN Geräte werden erkannt und der Controller kann mit dessen Eigenarten umgehen
• Modell Inspektor erfunden -> alle Vorgänge zum auslesen zusammengefasst, inkl. testen des Entity -> anlegen einer Datenbank um alle statischen Objekt zu speichern. So müssen Sie nicht erneuert gelesen werden -> verkürzt die Zeit des auslesen erheblich. (noch nicht richtig fertig )
• Bugs beseitigt, eins hat mich bis heute beschäftigt -> falsches Value aus einer Struktur übergeben, um es genau zu sagen die Sequenz ID übergeben anstatt einer Zeit . Wirklich toll wenn der Timeout immer größer wird, um so mehr Pakete gesendet werden ...

Weitere Baustellen, Datenbank, Optimierungen und noch vielen mehr -> ich arbeite daran, bei Interesse mehr zu einzelnen Neuerungen...

Dann werden wir den Thread mit 104000 Zugriffen mal wieder hochholen.

Gibt es was Neues? Ja einiges....

Intern wurden viele Sachen überarbeitet und das alles zu beschreiben wäre die Liste sehr lang.

Das wichtigste was zu erwähnen wäre, ist das das Projekt sich auch als Geräte Entity nutzen lässt. Dass der Controller sich im Netz zu erkennen gibt, ist ja nichts Neues, nun ist es aber auch so, dass sich alle Funktionen auch als Entity nutzen lassen. Mit Zugriff auf Hardwareebene! PTP, GPIO etc. werden dann möglich.

Die ENTITY Struktur wird intern erzeugt und in die API korrekt als Path umgesetzt. Zudem lassen sich auch mehrere Objekte aus dem Json setzen und abfragen. Auch das Command GET_DYNAMIC_VALUES wird voll unterstützt. Damit lassen sich aus dem Gerät man einem Paket mehre Values holen.

HTTPS und Verschlüsslung stehen auf der Liste für 2024 ....

Erste Gehversuche Hardware mit einzubinden, das was gut überlegt sein muss ist die Funktionen nicht zu tief im Code zu verschrauben. Ich werde das über cmake löst das eben dann spezieller nötiger Code mit eingebunden wird.

Default werden wird dann die bunte Kuh eingebaut, ich habe mit Modbus auch herum experimentiert. Hier wäre der Vorteil bzw. die Möglichkeit unabhängig vom System wo der Controller läuft zustände auf Hardware zu legen. Es wird sich aber auf simple Zustände beschränken, Entity Vorhanden, PTP Ready, Flow Ready oder ähnliches. Da bin ich gerade am basteln wie man das am besten lösen könnte.

Der Grund ist weshalb ich die Möglichkeiten überhaupt schaffe es als Entity zu verwenden ist jener den Controller Teil zu testen. Ich muss mein Geld nicht mehr in Geräte investieren . Das einzige dumme ist nur wenn ein Fehler drin ist, dann ist dieser auf beiden Seiten drin und es schaut so aus als würde alles funktionieren. Immer wenn sich was ändert, lässt man einen Test durchlaufen und schaut ob die API auch noch passt. Nebenbei wird das Projekt auch für andere Interessant die keinen reinen Controller brauchen.

Zitat von karel noon

Jetzt könntest du das ganze Projekt ja an Joyned oder D&B/Lacoustics verkaufen

Ich glaube die haben kein Interesse daran und Hive ist ja keine schlechte Lösung. Zumal mein Projekt ja für den Endanwender zunächst kaum brauchbar ist. Wer will sich mit einer Json basierten Lösung herum schlagen? Interessent wird mein Projekt für Medienhäuser wo über die API AVB Geräte leicht einbinden lassen. Das hat man bei den Mitbewerbern wenn man sie so nennen mag auch schon erkannt.

Das größte Kapital ist mein Wissen welches ich über das Projekt erlangt habe, nur das haben die Mitbewerber erkannt .

Joyned setzt auf Xmos und das sehe ich kritisch. Man ist von einem Halbleiterhersteller abhängig. Der Code ist nur schwer auf anderen Plattformen portierbar und er wäre prinzipiell auch nicht lauffähig. Geht die Firma Xmos unter geht das Projekt unter und genau das wäre mir als Hersteller zu heikel.