Fragen zum tpm2-Protokoll

  • Na ganz einfach: Wenn ich deine universelle Ethernet-XMega Platine nachbaue oder kaufe, dann möchte ich gern eine andere Matrix damit betreiben... Oder ich hab zwei Matrizen und nur ein "teure" Hardware um die zu betreiben und möchte gelegentlich zwischen der Indoor und Outdoor Matrix wechseln... Einstellen kann man alles bei Glediator, aber wieviel Packete denn abgewartet werden sollen, ist nicht ganz klar definiert...


    Wie gesagt, das Ganze ist nicht so schlimm, wollte es nur mal Ansprechen...
    Hm egal, wie gesagt, man kann ja beim ersten Durchlauf erstmal alle Packete verwerfen und schauen, welches Packet vor dem 0 Paket das höchste war, oder man zählt die Bytes von der Headerlänge runter (Fehler wenn Paket 0 zu früh kommt)... (geht sicher auch ziemlich gut)...
    Was ich halt nicht möchte ist ein Empfangsmodule was erst mit der Matrix bekannt gemacht werden muss... Da kommen eh noch nen paar Settings die man nicht so einfach umgehen kann (WS2811 oder WS2801 etc.)...


    Grüße


    Basti :)


    P.S. Mir gehts darum um folgenden Gedankengang: "Wenn die Verbindung so läuft wie sie soll, dann ist immer alles gut. Aber was ist, wenn mal ein UDP Paket "lost" ist? Nagut, ist nur Licht.... vielleicht bin ich einfach schon wieder zu Ängstlich bei der Sache =)

  • dann möchte ich gern eine andere Matrix damit betreiben... Oder ich hab zwei Matrizen und nur ein "teure" Hardware um die zu betreiben und möchte gelegentlich zwischen der Indoor und Outdoor Matrix wechseln...

    Ah, jetzt verstehe ich, was Du meinst - an so nen Fall hatte ich gar nicht gedacht, bei mir gehört das zusammen, "die Matrix selbst" (also Pixelplatinen o.ä.) und das kleine Board dazu, das letztlich nix anderes macht, als Daten durchzuschieben ;) (ggfs. Standalone-Programme).


    Da ist bei mir einfach die "Philosophie" anders, so ne Matrix ist für mich ein Trumm, an das Strom und Datenleitung kommt, da wird nicht noch irgendein Modul getauscht, bzw. so ne Platine für mehrere Anordnungen von Pixeln verwendet - das ist ja bei den Gesamtkosten der Matrix nur ein kleiner Teil...


    (weiß nicht, wie ich's genau erklären soll - aber für mich wäre das so, wie wenn ich z.B. mehrere Movingheads habe, bei denen ich die Hautplatine jeweils in den einsetze, den ich benutzen will... :D)


    aber klar, sowas gibt's auch - z.B. auch bei den kleinen Chinesen-Controllern mit LED-Display oder Onumen-Dingsbums, wo man in der SW am PC so Sachen einstellt...


    Da kommen eh noch nen paar Settings die man nicht so einfach umgehen kann (WS2811 oder WS2801 etc.)...

    Das ist geanu der Punkt! - wenn cih auch nur *irgendwas* an dem Teil einstellen muss, dann ist's schonh wurscht, dann brauche ich eh' ein Display oder DIPs oder PC-Einstell-SW, wasauchimmer dazu, und dann macht's auc nicht den großen Unterschied, ob ich nun die Paketanzahl und Größe auch noch einstelle (bzw. die SW das anhand der eingestellten Matrixgröße selbst errechnet)...


    für sowas wurden ja auch Befehle genormt, die werden noch veröffentlicht... ich bin nur noch nicht dazu gekommen, berate mit Pepe gerade noch darüber... die letzten 4 Wochen keinen einzigen freien Tag, muss jetzt auch gleich in's Bett, weil morgen früh raus...


    ich kann den Pepe ja noch mal fragen, schaden würde es ja nicht, statt nur einem Paket-Byte die Info "Paket x von insg. y" zu schicken, noch ist das ja nicht so verbreitet, dass man's nicht noch easy ändern könnte... ;)


    Und ja, wenn da mal ein Paket verloren geht, fällt das gar nicht unbedingt auf, hängt halt auch von der Animation ab - wenn's eh' hektisches Blinkern ist, dann wohl nicht, bei nem langsamen Plasma gibt's dann mal nen kurzen Ruckler...


    das lässt sich aber so und so nicht vermeiden, wenn ein Paket verloren wurde, was willst Du machen..? - Du könntest dann z.B. den ganzen Frame droppen, damit's keinen "halb/halb" gibt - aber dann stockt die Animation auch mal kurz... wenn's "ganz sicher" sein soll, müsste man halt z.B. auf TCP statt UDP setzen, irgendwas wo das Paket noch mal gesendet wird, wenn's nicht bestätigt wurde...

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • das lässt sich aber so und so nicht vermeiden, wenn ein Paket verloren wurde, was willst Du machen..?


    Na das Pakete einfach nicht abschicken, wenn das letzte Paket fehlt -> kein Flackern. Sonst würde ich es vielleicht abschicken, wenn auf einmal wieder das Paket 0 kommt...


    Wenn natürlich die Gesamtbytes im ersten Frame drin stehen und dann nur noch tmp2.net Daten folgen, hätte man das Problem auch nicht...


    Ich denke auch, hier könnte man sich nochmal mit Pepe abstimmen und etwas optimieren. Den IC wollte ich letztendlich über Wahlschalter eindrehen lassen, oder Stellung 0 -> EEPROM Daten per USB reingespielt.


    So kann man recht frei agieren... also dumme Senke und schlaue Quelle... ums mal zurück auf die Bühnentechnik zu bringen: da ist das ja auch öfter so, oder setzt es sich durch, dass jeder Slave mit USB oder Speicherkarte konfiguriert wird?


    Grüße


    Basti

  • Wenn natürlich die Gesamtbytes im ersten Frame drin stehen und dann nur noch tmp2.net Daten folgen, hätte man das Problem auch nicht...

    Das verstehe ich nicht ganz - Du meinst, man schickt einen Frame tpm2 mit Header, darin die Gesamtlänge, und bei mehreren Paketen kommen die dann noch einfach als UDP-Pakete ohne alles weitere (also ohne eigenen tpm2-Header) hinterher..? - da kannst Du ja noch weniger feststellen, ob was verloren gegangen oder durcheinander gekommen ist...


    ich finde den Gedanken immer symphatischer, einfach ein weiteres Byte dazu zu nehmen (macht das Kraut auch nicht fett), dass die Zahl der Pakete angibt - ist dann auch ganz easy auszuwerten, wenn aktuelle Paketnummer = Zahl der Gesamtpakete, ist der Frame komplett...


    oder Stellung 0 -> EEPROM Daten per USB reingespielt.

    Das finde ich etwas umständlich - da braucht man ja ne zweite Verbindung zum konfigurieren...


    also Beispiel, ich habe ne Matrix mit ner Ethernet-Buchse dran im Netzwerk, oder per Wlan-Modul, da kann ich doch gleich auch die Konfigurationsdaten (per extra dafür definierter tpm2-Befehle) da hin schicken, statt dass ich dann zum konfigurieren noch mal extra USB anstöpseln muss...


    ums mal zurück auf die Bühnentechnik zu bringen: da ist das ja auch öfter so, oder setzt es sich durch, dass jeder Slave mit USB oder Speicherkarte konfiguriert wird?

    Nee - da gibt's aber häufig auch nix zu konfigurieren (ausser der DMX-Adresse).


    Analogie: Bei nem Movinghead ist z.B. vorgegeben, Kanal 1 = Pan, 2 = Tilt, 3 = Rot, 4 = Grün, usw. - das ist fest gelegt im "dummen Empfänger", ich muss die Sende-SW dafür passend konfigurieren.


    Ebenso ist bei mir "in der Matrix" *festgelegt* z.B. sie erwartet 3 Pakete á 1.024 Bytes, da muss ich ebenso *nix* konfigurieren, weder per DIP, noch per USB oder Speicherkarte - ich muss nur im Glediator in der Patch-GUI das passende einstellen.


    Das ist mit Deiner Anwendung nicht unbedingt vergleichbar, eine Umsetzer-Platine, die mit ständig wechselnden Matrix-Größen/-Konfigurationen betrieben wird...


    klar gibt's auch DMX-Geräte, die man konfigurieren kann (bei meinen LED-Wacklern z.B. Dimmerkurve, 4-16-Kanal-Modus, Pan inverse, Tilt inverse, etc.) - aber das macht man eben mit Tastern und Display am Gerät selbst, da wird auch nicht bei den DMX-Daten mitgeschickt, in welcher Konfiguration das Gerät nun betrieben wird... das wird am Empfänger eingestellt, nicht in der Sende-SW

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Mit Pepe ausgemacht: wir erweitern das tpm2.net um dieses Byte für die Gesamtpaketanzahl.... ;)


    die nächste Glediator-Version wird das dann so ausgeben, werde das im Protokoll-Thread noch vermerken (kommt nach dem Paketnummer-Byte)...


    ist dann zwar bisschen doof, weil ja schon tpm2.net-Empfangsroutinen rumgeistern, die dann auch geändert werden müssen - aber jetzt geht's noch, je später, desto schwieriger zu ändern...


    Ich finde es ehrlich gesagt schon auch gut, bei so Platinen, die nur Pixel durchschieben o.ä., ist es so halt einfacher festzustellen, wie viele Pixel es insgesamt sind, und dann Speicher und Ausgabe automatisch anzupassen...

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • This is a custom firmware for the esp8266 wifi module that will drive a strand of ws2812 LEDs using the TPM2NET protocol. I was successful at driving 132 LEDs (11x12 matrix) using this firmware and the pixelcontroller (v2.1.0-RC1) software. I expect it to operate more LEDs (hopefully up to 512 LEDs) ... This is based on work by Charles (cnlohr) and Frans (Frans-Willem)


    http://github.com/sfranzyshen/esp8266_tpm2net_ws2812

  • @sfranzyshen
    It looks like your tpm2.net implementation doesnt support multiple blocks. This is very important if you want to drive more LEDs. If your channel count + protocol overhead exceeds the network mtu size, you will run into trouble with fragmented network packets. Thats why there are multiple blocks inside the tpm2.net protocol, so we can send a huge channel count with multiple network packets to avoid fragmentation. Most of the small tcpip stacks inside a microcontroller cant deal with fragmented packtets. See this post: Jinx! - LED Matrix Control ... und die nächste Matrix Software ...

  • @sfranzyshen
    It looks like your tpm2.net implementation doesnt support multiple blocks. This is very important if you want to drive more LEDs. If your channel count + protocol overhead exceeds the network mtu size, you will run into trouble with fragmented network packets. Thats why there are multiple blocks inside the tpm2.net protocol, so we can send a huge channel count with multiple network packets to avoid fragmentation. Most of the small tcpip stacks inside a microcontroller cant deal with fragmented packtets. See this post: Jinx! - LED Matrix Control ... und die nächste Matrix Software ...


    I am having problems trying to implement this ...
    tpm2 - Protokoll zur Matrix-/Lichtsteuerung


    0) Paketnummer first packet starts with 0x01?
    1) when Paketnummer == Anzahl Pakete all packets are done for frame?
    2) when NO frame split Paketnummer == 0x00 or Paketnummer == 0x01 && Anzahl Pakete == 0x01?
    3) pixels start numbering at 0? within Framegöße in 16 Bit?


    Here is my code ...

  • @sfranzyshen
    packet number (Paketnummer) always starts with 1, packetnumber=0 or packetcount=0 should never appear. If packet number == packet count (Anzahl Pakete) means its the last packet of the frame. if there is only one block, its the same: packt number=1 and packet count=1.
    The framesize (Framegröße) is given in 16bit (hi byte first), first payload byte (Nutzdaten) is the first pixel (means starting at 0). But attention if there are multiple blocks, the given framesize is the blocksize. The resulting
    framesize (buffersize you need) would be <= packet count * framesize (the last block can be smaller, for example main frame size 1500 with a block size of 800 will give you the first block 1 of 2 with a size of 800 and the block 2 of 2 with a size of 700.


    So I would implement it in that way:

    • wait for a tpm2.net packet with packetnumber 1
      calculate max buffer size with framesize * packetcount and reserve buffer
      copy the payload of this packet into the buffer at pos 0 and save the inital framesize
    • copy every payload from packets you receive into the correct place inside the buffer: pos = saved initial framesize*(packet number - 1)
    • if the packetnumber == packetcount get the correct overall framesize: (packet count - 1) * framesize + last framesize (can be smaller, see above)
      output the buffer to the LEDs, with the calculated overall framesize
    • again wait for a tpm2.net packet with packet number 1
  • Cool .. if you have any questions feel free to ask :)


    Found in another tpm2 spec sheet (Offizielle TPM2 Specs), that it is possible to send a packetnumber 0 when there are no mutliple blocks, thats not clearly stated out, so maybe you will change line 20


    Code
    if (packagenum == 0x01 && numpackages == 0x01) { // no frame split found


    to


    Code
    if (numpackages == 0x01) { // no frame split found


    just to be sure.

  • Cool .. if you have any questions feel free to ask :)


    we would like announce that we are expanding our testing to other chipsets ... and could use some help testing ... of course this means you will need a ESP8266 handy :) and either a strand of lpd6803 or ws2801 ... we are looking to test these with up to 512 pixels ... but any testing would be greatly appreciated.


    https://github.com/sfranzyshen/esp8266_tpm2net_lpd6803
    https://github.com/sfranzyshen/esp8266_tpm2net_ws2801

    and of course the original ws2812 code that has been successfully test with jinx & 16x32 (512 pixels)

    https://github.com/sfranzyshen/esp8266_tpm2net_ws2812

    thanks

  • Hallo,


    kann mir Anfänger jemand erklären wie Befehle funktionieren? TPM2.Serial.
    Ich habe das als Ping: 0xC9, 0xC0, 0x00, 0x02, 0xC0, 0x20, 0x36 bekomme aber keine Antwort.
    Oder Master-Helligkeit: 0xC9, 0xC0, 0x00, 0x03, 0x80, 0x0A, 0x10, 0x36 ...nix passiert.


    Daten schicken funktioniert.
    Dazu aber eine Frage: Muss ich periodisch Frames hinschicken oder geht auch 1x komplett und ein Befehl das endlos zu wiederholen?


    Ich benutze den Diamex LED-Player-S2, WS2812. Ist nichts großes, nur ein LED-Streifen.

  • Na, dann sind die Befehle wohl einfach in diesem Diamex-Player nicht implementiert... müsstest Du dort nachfragen.

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Das macht Jinx intern, wenn Du da den Master-Regler runter ziehst, werden einfach die Werte vor der Ausgabe noch mal runter gerechnet. Da wird aber kein Befehl ausgegeben, dass das externe Gerät das dimmt.


    Ob die Befehle richtig sind, kannst Du ja in der Doku nachschauen... ich denke schon.


    Da wurde damals halt einiges auf Wunsch diverser User mit dazu gepackt, verwendet wird davon m.W. eigentlich nix... ;) - ich selbst habe da auch einige Kommandos konzipiert, die dazu gedacht waren, Geräte an einem Bus zu steuern, also ähnlich KNX oder Dali... dann aber auch nie verwendet.


    In der Praxis wird tpm2 eigentlich nur dazu genutzt, Pixeldaten frameweise zu übertragen, also LEDs damit anzusteuern...

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!