Beiträge von marcoboy

    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 ;)

    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.




    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.



    Nö denn deine Berechnung hat einen nicht unbedeutenden Schönheitsfehler der nennt sich Leistungsfaktor :huh:.. 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 :D

    Tadaaa es ist ein Bild ein Bild :D..


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


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