Ankündigung

Einklappen
Keine Ankündigung bisher.

Intepretation von cEMI raw frame daten?

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    Intepretation von cEMI raw frame daten?

    Hallo,

    ich bin einer der Gründer des Apache PLC4X Projektes.

    Um mein baby auch zuhause einsetzen zu können, arbeite ich gerade an einem PLC4X Treiber für mein KNX System zuhause. Generell bin ich in der Lage alle UDP Pakete meiner Gira Knx/IP Schnittstelle zu interpretieren soweit mich die KNX Protokoll Spezifikation gebracht hat. Nun hänge ich ein wenig an den L_Busmon.ind Paketen. Genau da wo auch der WireShark "RAW Frame" sagt und die KNX Spec mir mitteilt, dass sie ab hier nicht mehr zuständig ist ;-)

    Zwar habe ich schon diese Infos zu Rate gezogen: https://www.dehof.de/eib/pdfs/EMI-FT...age-Format.pdf, allerdings erklärt diese nicht alle Fälle.
    z.B. bekomme ich viele Pakete, die als Daten nur ein byte mit "0xCC" enthalten. Das lässt sich in dem schema irgendwie nicht abbilden (Binär 1100, bei dem also das reserved Feld, das eigentlich 0 sein sollte, 1 ist). Auch sieht es so aus, als wenn das "Kontroll -Feld 1", wenn es bei mir 0xBC ist kein Kontroll-Feld 2 zu haben scheint, sondern direkt mit der Quell-Adresse weiter macht.

    Gibt es irgendwo genauere Informationen über das encoding? Ich bin auch bereit Specs zu erwerben.

    Gruß,
    Chris

    #2
    Hallo Chris,

    da musst du die das Frameformat auf dem Medium anschauen, für TP1 also Volume 3/2/2 der KNX Specification.
    Die 1-byte L_Busmon.ind Messages beziehen sich auf das LinkLayer-ACK auf TP1. 0xCC ist ein LL_ACK.

    Gruß, Klaus
    Zuletzt geändert von Klaus Gütter; 08.11.2019, 05:46.

    Kommentar


      #3
      Hi Klaus,

      Vielen Dank schon mal für die Info ... ich hatte zwar in den ganzen Dokumenten gesucht nur irgendwie hat die spec nicht zu meinen Suchbegriffen gepasst ;-)

      Verstehe ich das dann in Sektion 2.2.2 richtig, dass in dem fall ein Acknowledgement Frame durch bit4=1 im Control field impliziert wird (bit6 ist in dem Fall egal), ob es sich um ein polling frame handelt oder ein normaler Data Frame wird dann durch bit6 entschieden (bit4=0 und bit6=0 -> L_Data-Frame, bit4=0 und bit6=1 -> L_Poll_Data-Frame)

      Verstehe ich das dann auch richtig, dass im KNX zwei nachrichten verschickt werden eine Nachricht von Der Quelle zum Ziel und dann gibt es zurück nur ein Ack zurück (Die nachrichten mit dem 0xCC) ... weil ich allerdings alles vom IP Gateway zur Software mit UDP tunnele gibt's für jede dieser KNX nachrichten noch ein UDP ACK zum IP Gateway zurück?

      Gruß,
      Chris

      Kommentar


        #4
        Hallo Chris,
        Alles richtig.
        Gruß, Klaus

        Kommentar


          #5
          Vielen Dank ... endlich verstehe ich genau was mein Haus mir sagen will ;-) ... hoffe ich kann im nächsten Apache PLC4X projekt auch den KNCnet/IP Treiber releasen.

          Vielen Dank für eure Hilfe,
          Chris

          Kommentar

          Lädt...
          X