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

    Counterfeiter schrieb:

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

    Counterfeiter schrieb:

    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!

    Pesi schrieb:

    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

    Counterfeiter schrieb:

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

    Counterfeiter schrieb:

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

    Counterfeiter schrieb:

    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!

    esp8266_tpm2net_ws2812

    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)

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

    Seddi schrieb:

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

    Quellcode

    1. uint16_t framebuffer_len = 0;
    2. unsigned char framebuffer[1536]; //max 512 rgb pixels
    3. static void ICACHE_FLASH_ATTR tpm2net_recv(void *arg, char *pusrdata, unsigned short length) {
    4. unsigned char *data =(unsigned char *)pusrdata; //pointer to espconn's returned data
    5. if (data && length >= 6 && data[0]==0x9C) { // header identifier (packet start)
    6. uint8_t blocktype = data[1]; // block type
    7. uint16_t framelength = ((uint16_t)data[2] << 8) | (uint16_t)data[3]; // frame length
    8. uint8_t packagenum = data[4]; // packet number 0-255 (0x00 = no split)
    9. uint8_t numpackages = data[5]; // total packets 1-255
    10. if (blocktype == 0xDA) { // data command ...
    11. if (length >= framelength + 7 && data[6+framelength]==0x36) { // header end (packet stop)
    12. if (packagenum == 0x00 || numpackages == 0x01) { // no frame split found
    13. unsigned char *frame = &data[6]; // pointer 'frame' to espconn's data (start of data)
    14. ws2812_out(frame, framelength); // send data to strip
    15. } else { //frame split is found
    16. os_memcpy (&framebuffer[framebuffer_len], &data[6], framelength);
    17. framebuffer_len += framelength;
    18. if (packagenum == numpackages) { // all packets found
    19. unsigned char *frame = &framebuffer[0]; // pointer 'frame' framebuffer
    20. ws2812_out(frame, framebuffer_len); // send data to strip
    21. framebuffer_len = 0;
    22. }
    23. }
    24. }
    25. }
    26. }
    27. }


    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „sfranzyshen“ ()

    @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

    Dieser Beitrag wurde bereits 7 mal editiert, zuletzt von „Seddi“ ()

    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

    Quellcode

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


    to

    Quellcode

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


    just to be sure.

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „Seddi“ ()

    Seddi schrieb:

    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.

    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)

    github.com/sfranzyshen/esp8266_tpm2net_ws2812

    thanks

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „sfranzyshen“ ()