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

  • @ojacques
    You can create a chase that doees your complete show at once (its not necessary to record into a jnr file) and start jinx withe the chase via command line. So you can invoke "jinx.exe myfile.jnx -c 1" and it will immediatly start the first chase. So that fits nearly your idea, but you cant stop it via command line (OK, taskkill but I dont think this is really a good idea because it can block your output device if its serial based on restarting jinx).

  • Hi!
    Returning to OpenDMX and RFPixelControl. I have a burning desire to use such a scheme for Jinx:
    Jinx -> Arduino Nano (~7$) + NRF24L01 (~2$) ->))))) AIR ((((-> NRF24L01 (~2$) + Arduino Nano (~7$) -> WS2812 Strip.
    Extremely simple and cheap wireless scheme!
    If implement support for multiple OpenDMX-devices:
    DMX USB 1 - Universe 1
    DMX USB 2 - Universe 2, etc ...
    than it is possible to build and quite big matrix.
    I have it running on Madrix, but the demo :(
    Jinx!
    Oops...
    Thanx! ;)

  • When I got you right, you are asking for Jinx! to support E1.31 as output protocol ? Does that really use someone, I personally think this will never be used as a Standard, thats why I never looked about. I can look into the specs (dont know how it is designed in detail) and see if its an option.

  • I cant follow you ... Enttec OpenDMX is a (sure FTDI based) USB/DMX Interface, which uses a much too complicated driver model and api. Do you want to point out that the RFPixelControl Software on an Arduino acts like an Enttec OpenDMX on the USB side and needs the Enttec driver to work ? Thats a complete protocol overkill ;)

  • And again
    Oh, no, no ! :)


    I understand that any software supports OpenDMX ( tested on MADRIX, Vixen, Freestyler) " sees" any FTDI-chip connected to USB, as Enttec USB DMX device.


    Software does not work with firmware RFPixelControl, but with the FTDI-chip mounted on the Arduino, through a virtual COM-port. Sent from the FTDI-chip serial data go to ATMega328, which transmits data via SPI on nRF24L01.


    Therein lies the appeal of this solution. Arduino works and how Enttec USB DMX device , and as a translator on the radio.
    Only need to "teach" Jinx work with OpenDMX and send different DMX universes on different COM-ports.

  • I want OpenDMX :)
    My opinion. OpenDMX more common than MiniDMX. And he is more accessible - any Arduino on FTDI chip can become it.


    I am not a professional in LED matrix, so I advocate simple and low cost solutions.
    I've been looking for a cheap solution for WIRELESS control LEDs.
    RFPixelControl - the easiest thing I've found. And it works great with Madrix and Vixen. But I do not like neither one nor the other. The first - pricey, the second - not intended for matrix.


    I know I was not alone in this world ;)
    We are really looking forward to supporting free software OpenDMX! :)

  • Sorry, in German, my English is too bad to understand ;) - maybe you try Google Translate...


    Seddi: Ist es denn ein großer Aufwand, noch ein weiteres Protokoll zu implementieren...?


    Wenn ich das richtig erinnere, ist das "Open DMX Protocol" praktisch so, dass der PC direkt selbst DMX erzeugt: Die Schnittstelle wird auf eine niedrige Baudrate gestellt und ein Nullbyte gesendet - das erzeugt den Break. Dann wieder auf 250 k, das Startbyte senden, und dann die Daten, fertig ist die Laube...


    interessant wäre es im Prinzip schon, da dann auch Leute, die von Basteln keine/wenig Ahnung haben, vergleichsweise günstig mit so nem Interface DMX ausgeben könnten - ich schreibe extra "vergleichsweise günstig", das Enttec-Dings ist ganz schön teuer dafür, dass es nur ein USB/RS485-Wandler ist, halt mit XLR-Buchse fertig in nem Gehäuse...


    und zusätzlich interessant eben dann durch die Funkübertragung wie oben geschildert - wobei ich hier ein bisschen den Sinn anzweifle, soo schnell und stabil sind diese Module nicht, insb. wenn mehrere gleichzeitig in Betrieb sind... so zumindest bei meinen Versuchen (habe diese Dinger auch hier), bei ihm scheint's wohl ganz gut zu funktionieren...?


    Bei dem Projekt läuft wohl ein Sketch auf dem Arduino, das Daten über "Open DMX" empfängt, und dann entsprechend an das nRF24L01 weiter gibt zum senden - er könnte also auch einfach die Open-DMX-Empfangsroutine in dem Sketch durch eine tpm2-Empfangsroutine ersetzen, dann hätte er das, was er will...


    aber k.A., wie ich das auf Englisch erklären soll... :D - insb. da ich von Arduino auch sehr wenig Ahnung habe...


    Nur so für Leute, die das auch interessiert: Pixeldaten funken geht echt easy mit Wlan und den RN-171-Modulen - habe ich hier auch laufen, einfach Daten per Artnet ausgeben, RN-171 empfängt die, und eine SW auf dem µC gibt sie dann für WS2801 aus...


    bei mir gehen da easy 4 Universes, dazu bräuchte man 4x so ne Funkstrecke aus je 2x Ardunio+nRF24L01, ist da also mit 72$ schon teuerer als ein µC mit RN-171 dran... klar, wenn man nur ein Universe braucht, dann ist die andere Lösung günstiger, einfach weil der RN-171 schon über 30 € liegt...


    der neue SEDU kann das übrigens auch, also für die, die nicht selbst basteln wollen...

    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!

  • Hi Pesi,


    unter OpenDMX ist halt Protokollmässig nix zu finden .. man landet auf OLA und das kann ja alles mögliche. Hab auf die schnelle im Netz nix gefunden über ein "Open DMX" Protokoll ... Aber quasi DMX auf ner seriellen zu machen ist ja irgendwie auch quatsch. Ein zusätzliches Output Device ist nicht das Thema .. meine Schwierigkeit ist .. ich find kein Protokoll unter "Open DMX", ich find ja nicht mal das da irgendwo steht das hier DMX auf ner normalen seriellen gemacht wird, oder was auch immer ;)
    Ich seh nicht das Problem ein Protokoll in Jinx zu implementieren, wenn man weiss WAS man da implementieren soll :D

  • ja, das hat bei mir damals auch lange gedauert, das zu finden, hab' die Quelle leider auch nicht mehr...


    jedenfalls läuft das so, bei diesem Interface, da ist nur ein FT232 und ein Bustreiber drin, DMX wird per SW erzeugt...


    klar ist das irgendendwo Quatsch, für den Hersteller aber ganz OK, wenn er so ein Trumm für den Preis verkaufen kann... :D


    ein Freund von mir hat so eins, für "Notfälle" (der benutzt Freestyler, falls sein anderes Interface mal kaputt geht), das funktioniert aber eigentlich ganz gut - wieso auch nicht, wenn ein kleiner µC problemlos DMX erzeugen kann, dann ein PC ja erst recht...

    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!

  • Just a little Web research. With my second guessing today I was absolutely right:


    Zitat

    Do you want to point out that the RFPixelControl Software on an Arduino acts like an Enttec OpenDMX on the USB side and needs the Enttec driver to work ?


    That is correct, this software acts like an Enttec OpenDMX, as a lot of other interfaces do as well, because the hardware design is "open". So there are two possibilities to directly support such a device.
    1.) Using the Enttec Windows Driver and Jinx! will talk via the API to this driver
    or
    2.) Build an own driver inside Jinx! which will produce a serial DMX signal on the FTDI (which would be the better way, because we are independent of other pieces of software), a good starting point here is the linux driver, where you can read out the "protocol" and how its done to set the break state on the ftdi: http://www.erwinrol.com/open-dmx-usb-linux-driver/


    I will put it on the list and we will see. Maybe there is anywhere a small piece of software in the web who will receive Artnet and send it over an OpenDMX "Interface". This would be useable till I got the time to buy me an OpenDMX and write a driver into Jinx! ;)

  • hm, mir glaubst Du nicht.....?


    noch mal: das "Enttec Open DMX" ist nix anderes als ein USB->RS485-Konverter mit FT232 - da ist keinerlei µC oder sonst noch was drin!


    daher gibt es da auch kein "Protokoll" zwischen PC und Interface, Du erzeugst einfach mit Deiner SW selbst DMX am Ausgang des FT232


    siehe dazu auch hier:

    Zitat

    The OpenDmx USB circuit simply consists of a USB to serial converter (FT232BM)
    and a driver block (max485). This circuit takes care of transforming
    your signal from USB to Serial and from Serial (RS 232) to DMX (RS485)
    but it does not care about what are you sending (transmitting). The
    signal itself has to be produced by your PC. The PC has to take care of
    timing and order of the signal.


    EDIT: Oh, da kam ein Post dazwischen, hab' ich nicht gesehen...

    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!

  • Zitat von Pesi


    EDIT: Oh, da kam ein Post dazwischen, hab' ich nicht gesehen...


    Yep alles etwas verwirrend heute :D


    Ich mein das macht ja Sinn um Dmx zu erzeugen, aber am PC Dmx erzeugen das auf einen Arduino geht der dann SPI draus macht ist eigentlich Humbug ... Egal. Ich wollte ja eh irgendwann ein "übliches" USB/DMX Interface implementieren ;)

  • Klar ist das Humbug, da irgendwie mit "Tricks" DMX rauszuwürgen, wenn das dann eine SW auf dem Arduino letztlich wieder in Nutzdaten übersetzt.


    Aber die werden das halt so gemacht haben (ich meine die Entwickler dieser Funklösung, dass die "Open DMX empfangen"), weil so viele SWs (Freestyler, DMXControl, Madrix, ...) das ausgeben können, das ist das einzig sinnvolle Argument dafür.


    Wie schon gesagt, man könnte das auch "andersrum" anpassen, indem man in diesem Arduino-Sketch die DMX-Empfangsroutine durch eine tpm2-Empfangsroutine ersetzt - für jemanden, der "Arduinoisch" kann sollte das ne leichte Übung sein...


    Aber wie schon gesagt, wenn Du das als Ausgabemöglichkeit mit einbaust, schadet das bestimmt nicht, weil's halt noch ne weitere gängige Möglichkeit ist, aus Jinx! dann DMX raus zu bekommen... der potentielle Nutzerkreis damit also wieder ein bisschen größer wird ;)

    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!