ARM ab oder ARM dran 
.. Ich habe mir mal eine Buildroot Umgebung für den RaspberryPi gebaut und damit auch eine toolchain. Auf deutsch... Linux System aus den Quellen erzeugt und die Werkzeuge um Programme für das System zu übersetzen.
Was soll ich sagen, der Controller lief auf dem Pi ohne Probleme 
. Ich werde mir mal auch eine für den beaglebone black basteln, denn der hat eine PTP fähige PHY oben..
Weiter geht es...
Was willste da boosten bei 5GHZ ? Dir ist schon bekannt das der AP mit bis zu 1000mW senden darf !? Die Kröte die man dabei schlucken musste ist eben das er diese reduziert sobald anderen APs auftauchen. Die 1000mW gleichen auch die schlechteren Ausbreitungsbedingungen aus. Das betrifft dann schon das Volk was sich vor dir aufbaut 
Oder kennst du ein Kommerzielles Produkt welches sich per REST API bedienen lässt und somit offen für alle anderen Gewerke wäre ?
Tatata... ein 4.4k Bildchen aus dem Memory vom Apple 
..
Das sind dann die ersten die darauf warten etwas für umsonst zu bekommen... Das Projekt kann schon mehr als das was auf dem Markt verfügbar ist und meine MONOLOGE bestätigen die Erfolge.
Glaub das nicht.. Es mag zwar sein das im 5GHZ Bereich weniger los ist aber, sobald ein anderer AP auftaucht oder Radar in Betrieb ist wird die Sendeleistung reduziert bzw. die Kanäle werden nicht benutzt.
Das sollte eigentlich das Problem im 2,4GHZ Bereich lösen, führt aber in der Praxis dazu das die Reichweite unter 2m sinkt .
Nö, auch Mesh Netze welche die Industrie gerade versucht an den Man zu bringen lösen das Problem nicht. Ein völlig überfrachtetes Band, welche nur noch mit Glück funktioniert.
Kauf dir einen Ethernet Adapter...
Die Handys sind in soweit ein Problem wenn sie sich versuchen mit deinem WLAN zu verbinden. Wenn die Service Set Identifier nicht sichtbar ist werden es die Handys auch nicht versuchen.
Das war jetzt gar nicht einfach 
.. Das Problem bestand in der libmicrohttpd und der Symptomatik das ich auf jede response vom Entity warten muss(wollte).. Es gab keine Möglichkeit den Post Prozess anzuhalten 
.. So das ich die Daten komplett einsammeln musste. Um Speicher zu sparen habe ich es nach versuchen so gebaut das die base64 Daten chunk weise decodiert werden, sie müssen eine Teilmenge von 4 haben. Sonst ist das base64 im Eimer. Den Rest der möglicherweise übrig bleibt kopiere ich um und hänge sie beim nächsten chunk an um sie zu decodieren. Das verfahren hat den Vorteil des immer noch weniger speicher braucht als das base64 als String abzulegen.
Diese decodierten Daten werden dann stückweise an das Entity gesendet ..
Es ist eine Zwischenlösung, da das ganze nicht taugt am 100MB zu übertragen. Als File die upload Daten zwischen zu speichern gestaltet sich leichter...
Was man natürlich machen kann ist die Daten mit mehren Request zu übertragen, das ginge natürlich ohne Probleme.
und nicht vergessen die Sicherung zu tauschen !
Das man so die Wirkleistung eines Brenners nicht berechnen kann... Die Angabe ist nicht einmal falsch, sondern die 207V sind die minimale Zündspannung, nicht die Brennspannung.. Ich habe es auch überlesen, da die eigentliche Brennspannung mit dem Strom die Größen sind an dem man die Drossel berechnet.
Beide MSR haben 70 V
Grundsätzlich muß zwischen Brennspannung und Zündspannung unterschieden werden. Zündspannung liegt immer zw. 2 - 5 KV.
Die Brennspannung kannst du bei dir auch messen, aber erst nach der Zündung.
207 V x 6,9 A macht bei mir 1428 Watt und nicht ca. 400 W
Keine Ahnung ob die bei Philips zuviel Gas eingeatmet haben......
Nö denn deine Berechnung hat einen nicht unbedeutenden Schönheitsfehler der nennt sich Leistungsfaktor 
.. In Anbetracht dessen lässt sich dann auch der Kondensator erklären...
Au auf den Sockel habe ich gar nicht geschaut... Wenn der Brenner erlöscht wird die minimale Brennspannung unterschritten. Das kann mehrere Ursachen haben, Drossel defekt, ja auch der Brenner kann defekt sein oder eben er passt nicht zur Drossel...
:edit nur mal im Interesse in den Schaltplan geschaut und festgestellt das dieser einen E gesteuerten Ballast hat.. Da gibt es noch 100 weitere elektronische Gründe...
Die Frage kann man leicht beantworten wenn man ins Datenblatt der Brenner schaut.
Die MSR400 hat min 207V 6,9A
OSRAM HSR400/60 67V !!!
Sie zündet und dann steigt der Strom enorm an.. Folge Drossel kaputt, Brenner im Eimer, Zündgerät auch kaputt..
Um diesen Brenner zu verwenden, musste du die passende Drossel und Zündgerät verwenden.... So das sich am Brenner auch die 67V mit Strom einstellen...
Wenn die Dioden durch sind, ist der Rest auch im Eimer
Das hängt damit zusammen das man an der Stelle genau 12V braucht und meine Vermutung der Strom in der Praxis im Knick der Diode zum erliegen kommt. So je nach Ergebnis eine 12 bzw 13V Z-Diode zum Einsatz kam.
Man hat es vermutlich einfach ausprobiert und die Übernahmeverzerrungen gemessen.
Es fliegt dir da nichts um die Ohren wenn der Rest funktioniert Um das Thema zu umgehen würde ich eine noch ganze Diode mit mehren Strömen vermessen (im Knick ein paar mehr ) und dann in meiner Kiste versuchen mir welche zu suchen die ungefähr passen.
Wer gar keine Zeit hat -> lötet zwei Ösen ein und probiert einfach herum mit ein paar 12V/13V Exemplaren. Wenn knallt waren es nicht die Dioden 
Ja weil der Hersteller dann sortiert und garantiert das die Toleranz <2% liegt... Daran hat man bei der Produktion kein Interesse .
Ich hab nachgeschaut wo die Dioden drin sind... Einfach zwei Dioden vergleichen und ersetzen
Hierzu muss er aber den Strom wissen der durch die Diode fließt und dann anhand der Kennlinie ungefähr abschätzen welche andere Diode passt. Oder gleich abschätzten das es an dem Punkt relativ egal ist..
Tadaaa es ist ein Bild ein Bild ..
Was ist passiert ? Mir ist es gelungen im Memory Deskriptor beschrieben Inhalt auszulesen und als base64 zu encodieren .
Die Daten decodiert und wir haben ein gültiges Bild eines Apple Entitys. Welches sich im Browser ohne Probleme decodieren lässt. Der Vorteil darin ist das mit einen Request der Inhalt verfügbar ist und nicht noch mal ein extra Request um den Inhalt abzuholen. Man könnte das natürlich auch Binär übertragen, aber dann verlassen wir das Json Konzept.
Was noch gemacht werden muss -> senden per chunks an den Client und auch das übertragen von Daten zum Entity
Was ich noch überlege das ganze aus den Deskriptor heraus zu machen, somit muss man keine Adressen und Längen angeben.
Offenbar haben einige den Standard nicht gelesen 
, die Payload ist beim AECP begrenzt und deutlich kürzer als die mögliche.. Das hat einen Grund, man will das diese Pakete im QOS zwischen gequetscht werden. Sind diese zu lang passen sie kaum zwischen den Pausen..
Die meisten senden trotzdem längere Pakete...
Nun bin ich doch daran TLV umzusetzen, damit kann man auf den Speicher des entitys direkt zugreifen. Das ist der Mechanismus für Firmware Updates.
Apple hat sogar Bildchen hinterlegt, und vergessen die Adressen zu prüfen. Sie prüfen sie schon reichen mir aber den Inhalt trotzdem durch. 
autsch.. ich kann also im Speicher des Prozesses munter herum rutschen.
Ein dummes Problem ist das dieses Mechanismus den schreiben,lesen und ausführen mit einen Kommando erlaubt. Dazu bildet man eben mehrere TLV.. Das lässt sich aber in der Rest API nicht abbilden, des wegen kann man nur ein TLV pro Kommando absetzen.
So der stand ist jetzt so das alles zum neuen internen http Service portiert wurde Das alte Interface wurde entfernt...
Bevor was neues hinzu kommt werde ich den Core optimieren und auf Bugs abklopfen.
Dann kommt erst mal der Dicke Brocken mit der Datenbank um die Trafic aus den Geräten zu nehmen.
Der zweite Punkt ist der http Service -> File API, Session Management,TSL, Access Konfiguration
Punkt 3 Firmware Updates der Geräte..
Schaut mal auf der PLS nach AVB Geräten
Ja von Intel z.Bsp. Aber schon mal etwas für FPGA gemacht ? Wenn du ohne Module auskommen willst kannst du alles aus Gattern zusammen basteln. Willst du dir das ersparen musst du dein Portmonee weit aufklappen das wäre dann auch schon leer nachdem du die nötigen Lizenzen erworben hast um deinen Code zu erzeugen..
Für Rolf seinen Medienwandler ist das relativ einfach, für AVB schon etwas schwieriger und sehr umfangreich.
Xmos sollte ja eine alternative zum FPGA darstellen. Da es keine Interrupts gibt, sind zeitkritische Dinge planbar. Es ist aber immer noch ein Mikrocontroller mit mehrenden Kernen. Der auch einen Begrenzten Takt aufweist und wie es somit mal ist mehre Takte benötigt um einen Befehl auszuführen.
Nachteil sind auch die hohen kosten vom FPGA selbst. Ein ARM kostet ein paar Dollar.. Ein FPGA $40 und mehr..
Nunja eine Switch besteht aus zwei teilen. A: den Core der die Datenpakete transportiert. B: Ein System welches den Core steuert. Das System B ist ein normales OS z.Bsp Linux, auf dem man andere Sachen laufen lassen kann. Dort könnte man auch einen AVB Controller laufen lassen.
Diese China Switch basiert auf einen Marvell in dessen ein ARM mit einer Switch kombiniert wurde. Das Problem ohne die Dokumention über die Register ist das ganze nutzlos und ich hatte trotz alles versuche keinen Zugang zur Buildroot Umgebung um Treiber oder auch Programme für das System zu bauen.
Xmos ist für mich mittlerweile unten durch. Der Stack ist so etwas von Grausam gebaut und ungepflegt das es sich kaum lohnt den noch weiter an zufassen. Mittlerweile habe ich die schlimmsten Bugs behoben und mir Descriptoren gebastelt um den Controller zu testen.
Der größte Nachteil ist aber das der Xmos zu wenig Leistung hat. x-core200 hat zwar eine 1Gbit/s PHY macht aber bei ca. 44Mbit/s schlapp. In Channels ausgedrückt alles über 32Ch ist problematisch..
Ohne Traffic-Shaping kann ich den Controller dazu benutzen den Stream zu stören. Ich sende einfach 100000 AVDECC Pakete an das Gerät.. Um das zu vermeiden muss ich verhindern das ich das Gerät mit Trafic bombardiere. Ich könnte schauen in wie weit Antworten zurückkommen und den Sende Queue dann so steuern... Nächstes Problem ...
Es gibt immer wieder Ankündigungen das es einen AVB Stack der auf einen ARM läuft veröffentlicht, aber es entsteht ein ähnliches Problem. Zu wenig Leistung, für 1Gbit/s ohne FPGA nicht möglich.
Also 10 Jahre will ich nicht brauchen , bald ist aber ein Jahr vergangen seit dem ich an der Sache dran bin..
Aber es gibt Fortschritte, die Problematik mit dem Format bei Control und weiteren Kommandos ist gelöst.
Es bestand ja das Problem die Daten zu entschlüsseln da einige Informationen dazu nicht in der Antwort enthalten sind. Man musste also auch die Descriptoren lesen...
Das Entfällt und das macht der Controller jetzt für den Client. Voraussetzung das Control Value wurde mit einen Descriptor beschrieben... Sonst kommt es in base64 zurück.
So kann man das Value per GET auslesen und bekommt das inkl. Präfix im korrekten Format zurück. Das macht es für Clients besonders einfach und sie müssen nicht zwangsweise die Descriptoren auslesen.
