Jinx! - LED Matrix Control ... und die nächste Matrix Software ...

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

  • 64x32 is a large number of leds to be controlled.

    In principle, Artnet can handle this amount of channels. But I wouldn't use WiFi, the connection is not reliable enough. Sure, it depends on which kind of casting you are using - but with the experiences I made using Artnet over WiFi I would never control a matrix of this size via WiFi.

    If you think about buying a controller, I would look for a single controller capable of controlling all leds. Using multiple controllers you risk that they don't run synchronously. As far is I know, Jinx! and Glediator don't send a synchronisation signal - the commercial (and expensive) software Madrix does so; but it depends on the controller if it can handle this properly.

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

  • Habe mir jetzt den Akai APC Mini geholt. Leider bekomme ich die Midi-Ansteuerung bei Jinx nicht hin. Mir geht es erst mal um die Fader. Ich weiß nicht, was ich bei "Controller" einstellen muss.
    Wenn ich die Nummern dieser Abbildung eintrage gehen die Fader nicht.

    Mit MidiOX habe ich geschaut, welche Daten aus dem APCMini rauskommen, wenn ich einen Fader bewege.
    Ich habe es dann mit Zahlen von Data 1 probiert. Geht auch nicht.
    Leider gibt es im ganzen Netz keine Anleitung dazu.
    Need Help.

  • Habe die Lösung gefunden. Man muss alles auf Midi-Kanal 0 stellen, denn laut Anleitung: "

    : Jinx! will always start any channel count at zero. DMX normally starts counting in human order,
    means 1 is the first channel. So if you converting any DMX data to remotely control Jinx! you should take
    care about that and know that DMX channel 1 will get Channel 0 inside Jinx!"

    Jetzt gehen die Fader!