Has anyone happened to have instructions on how to receive TPM2.net with the Raspberry?
My plan is to control it with the Raspberry WS2812B LED. This also works perfectly.
The Raspberry should then receive the data via Jinx from a separate computer via TPM2.net.
I am grateful for every tip
Hi again Thismalor,
have a look at https://www.sfml-dev.org/tutorials/2.5/network-socket.php
It is what you are looking for.
Hi Pesi,
finaly it seems - which is very nice and welcome - that someone with genuine technical knowledge (and not only trivial questions) participates...
Creator of tpm2 - Germany must be mother of LED-science. Maybe you know your colleges - creators of Glediator or Jinx! and wake them from the dead 
Sorry if it happens to be you. Being foreigner, I do not know the historical background so well It is hapening me all the time. I was having a great discussion with a guy about problems with FastLED library, suggesting other libraries, untill I after many contributions found, that he was the creator of FastLED...
You are right about the speed of serial link - my mistake. When you come to 25frames/s, the serial is out for big matrixes. And you still do not include the time for displaying the received matrix before next frame arrives unless you can use DMA technique. But this is the world of a desperat user, when he is not capable to use the wired LAN.
Lately I have been able to write a program to receive TPM2.net over LAN on Raspberry, beautifully smootly displaying 64x32 effects which is a great anouncement, because it was really hard for a person not familiar with sockets programming etc. I also stumbled over the peculiarity (excuse me) having two different START bytes (C9 for TPM2 as opposed to 9C for TPM2.net) which almost made me to give up, when I (by obvious mistake) could not recognize the packets.
Well, my solution now works with Windows Jinx! directly LAN-onnected to Raspberry and I am working on getting it to receive TPM2.net from Glediator (the patching there is a terrible experience). I will also investigate it's limits when it comes to even bigger matrixes.
Thank you for discurraging me from using TPM2.net - It is obviously too late now I have chosen it, because of lost packets when trying to use Artnet over Wifi. The Artnet packets are short (max 512) so that you have to send many, which increases the chance for loosing one. For a couple of decades it might work well, but in today's city apartment with so many Wifi networks arround, there is terrible queue in the air for each packet. It is interesting how old predictions of eathernets insufficience for realtime control came true even in home-environment. I still do not understand, why and how Jinx! splits the packets into shorter (1410 long) frames (universes) and why it doesn't use the capability of much larger packets in TPM2.net. But development of Jinx! is obviously dead, which is a great shame.
Hi again,
I am happy to discuss the matter of controlling big matrixes.
And you guys, do not worry about English, you can still answer me in German. Google translator helps us in both directions, even if you might have objections against some syntax. Just try to keep your language simple, please.
Back to you HBB:
Recently I have managed to receive Jinx! TPM2.net protocoll over Wifi for a 64x32 matrix without loss of packets. Wifi is not reliable, but it is the only way, I can do it with my knowledge and resonably cheap hardware.
If controllers for single LED-strip are expensive, then I can imagine the price of multichanel controllers. I do not think the synchronization is much of a problem. The controllers send the electrical signals to the srips imediatelly when they receive the protocolled data. But I will see.
In the begining of my playing with LED-strips I built a cheap (Arduino nano) controller, that converts Glediator protocoll to the electrical signal for LED-strip. I am still using it. It is physically attached to the LED-matrix. It has many advantages.
1. it costs peanuts.
2. it is safe for the LEDs. If something happens with the cables, the sending computer or the power supply for the communication, the LEDs do not receive anything. All the protecting components (capacitor and resistor) are just calculated for the (very) short distance from nano to the strip.
3. the timing or the voltage of the electrical signal is not an issue.
4. There is no obstacle in speed. The LED-signal is about 800kHz, while Glediator protocoll uses 1000 kBaud. Everything is just delayed by one frame. If you would use the same for each segment of your complete huge matrix display, it is perfectly synchronized.
5. The RS232 or whatever serial protocoll is very well accepted by the industry and is developed for "larger" distances, which is certainly not the LED-driving signal. If I would need to use larger distance, I can easily find circuits to safely transfer the serial data levels (+12V/-12V) over suitable cables.
6. Many microcontrollers (like ESP32) have UART that uses some kind of DMA technique, so that you are not depending on the LED-library's implementation of SPI or whatever (like FastLED.show)
7. The only thing I need to do in the few fancy Arduino examples is to change FastLED.show to my SendGlediator() . This is of coarse not completely true for ex. Adafruit matrix.show. Adafruit are purists, that managed to hide the LED array for the users, so that controlling it is academicaly safer, but much slower, since you have to read it pixel by pixel instead of using memcpy()
The list could be longer. But the most important thing is, that my LED-matrix survived several years of harsh development. Yes, I burned a few strips' first LED in the beginning, so I made my lesson.
With all that said, I am still looking for a solution, where Raspberry accepts TPM2.net over LAN cable.
Hat jemand zufällig schon eine Anleitung wie ich TPM2.net mit des Raspberry empfangen kann?
Mein Plan ist es dann mit dem Raspberry WS2812B LED´s zu steuern. Dies funktoniert auch Perfekt.
Der Raspberry soll die Daten dann über Jinx von einen Seperaten Rechner über TPM2.net emfpangen.
Ich bin für jeden Tipp Dankbar
Hi Thismalor,
have you found any solution?
I am also very interested in this.
I suppose you have a decently large LED-matrix, so you have to transfer the huge data with TPM2.net. Mine is 64x32 and I am thinking of doing bigger (the effects are greater with big matrixes, but the number of LEDs grows even faster)
What I do so far:
My idea is, that the CPU-workload for big matrixes makes it impractical or even impossible to use Python. Therefor I use C in Raspberry. Since I have very good experience with Glediator protocol (it is even faster, than TPM2, because it uses 1000000 BAUD), I have written a serial Glediator protocoll receiver in C for Raspberry.
I found a sketch for ESP8266 that receives TPM2.net from Jinx! on Windows PC over Wifi and controls LED-strip directly. I rewrote this, so that it converts TPM2.net to Glediator protocol. Actually the ESP8266 was too busy to make it, so I adapted the sketch for ESP32 and use both CPU-cores in parallel (one for receiving from Wifi and the other for sending the serial data). ESP32 is known for unexplained issues of interrrupt problems, which makes it less suitable for the time critical control of LED-stripes. So one has to accept a few glitches in the movie. But since the glitches come in the Glediator protocoll, you are not jeopardizing the LEDs!
The difference to do it this way instead of letting Jinx! output the Glediator protocol directly is, that Glediator protocol (and probably any other serial protocol over 1 line) slows Jinx! down to lower framerate.
In this temporary solution I wish to replace the ESP32 with a C routine in Raspberry, that would receive the TPM2.net directly over LAN instead of Wifi. I have a program example (see here) how to comunicate from a LAN-client with Raspberry as LAN-server, but I am not capable enough to adapt it for receiving TPM2.net protocoll. It's not the TPM2.net protocoll itself (which is quite simple) but it is the one way LAN communication, that I am not successful with. I can see the LAN packets comming to Raspberry at the flashing connection lamp, but I don't know, how to read the packets. May be, someone here could help(?)
Alles anzeigenHallo,
bin neu im Forum und teste Jinx schon einige Zeit (WS2812b 60 x 90, 3 x DIAMEX LED-Player "M", Fernsteuerung über Artnet mit Android "AuroraDMX").
Unter Win7 hat auch alles bis auf Kleinigkeiten (Programmabsturz beim Konfigurieren der Countdownfunktion) sehr gut funktioniert.
Jetzt haben ich meinen Jinx Rechner auf Win10 umgestellt und seit diesem Zeitpunkt macht die Remote-Ansteuerung das wie von LED_Steve beschriebene "Geflacker" (schneller Wechsel zwischen alten und neuen Einstellwerten) Dieses dauert recht lange (10..30 Sekunden).
Hat jemand schon die gleichen Erfahrungen gemacht oder evtl. eine Lösung für dieses Problem?
Gruß Kai
Hi krawallo and others. (sorry again for English)
I am using Glediator an Jinx! for my LED-matrix 32 x 16 which I can drive with Glediator protocol over serial connection.
Latelly I have been thinking of larger matrixes. But before building one I have created an emulator on Raspberry where i can set (and modify) the size of the matrix and display it with the HDMI display on TV.
Suddenly there is a problem, how to send the huge data from Glediator or Jinx! for ex. 64 x 32 matrix. Both Glediator and Jinx! can still send the data with Glediator protocol over serial, but they slow down the frame-rate signifficantly.
Is there really no cheaper solution, than the 3 x DIAMEX LED-Player "M" (3 x £55 at Amazon)
I'd like to ask this great LED-fantast community, if anyone has built (or at least know of) an Arduino/ESP8266/ESP32/RPi solution to drive a decently large matrix of WS2812 or other LEDs.
I have tried with Artnet using ESP32 over Wifi for 64x32 matrix, with 16 universes, but it seems that packets are lost.
Sorry for English.
Does anyone know, why Sven does not answer his email sven@karschewski.de even if he on the page http://www.live-leds.de/ writes:
If you need any Information, found bugs or want to share some ideas and thoughts with me, feel free to contact me directly via email or comment the corresponding news post.?
Jinx! is fantastic and it would be great pity if it was dead.
Right now I have problem with the "text" command in Jinx! script.
1. there is a terrible mistake in the PDF jinx-usermanual-2.4 page 55, which leads to suspicion , that the text command does not work at all.
2. the command does not make it possible to display the " [double quote] character
3. the command does not make it possible to display the , [comma] character ("Hello, world" is impossible)
4. the command does not display the UTF-8 characters correctly (even if the "scrolling text" effect shows them correctly). (Ü impossible)
I believe this is a minor programming issue (just parsing the command line in right way).
If anyone would have any information, please, give me a hint.
