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

Jinx! - LED Matrix Control ... und die nächste Matrix Software ...
-
-
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.
-
Oh, no, no!
I was referring to Enttec OpenDMX, using FTDI-chip and virtual COM-port.
E1.31 uses Ethernet shield, which increases the cost and complexity of design.For me personally. I do not yet see that point in using E1.31, thars why not
study this technology. Most likely, this thing is worth. Maybe later ... -
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. -
Jinx! Supports to send to different serial ports, the question is which protocol you will using to send to your FTDI? MiniDMX and TPM2 are the most common at this time and Jinx! Supports this.
-
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! -
Maybe Im blind, but opendmx is a project and not a protocol ... The opendmx projects support various protocols ... Maybe some one can help me out. There is no protocol named OpenDMX or I am not able to find it ...
-
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...
- 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...
-
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 -
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...
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...
-
-
@godkiller
This is the API for the Enttec DMX driver, thats something complete different.@all
If anyone can provide me a link about "opendmx protocoll" it would be nice -
Just a little Web research. With my second guessing today I was absolutely right:
ZitatDo 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:
ZitatThe 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...
-
Zitat von Pesi
EDIT: Oh, da kam ein Post dazwischen, hab' ich nicht gesehen...Yep alles etwas verwirrend heute
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
-
So, hab mal einen von Enttec bestellt, dann kann ich mal ein paar Kannen ranhängen und rumspielen.
-
Hi it would be great if Jinx supports the E1.31 protocol instead Entec Open could be used this hardware https://github.com/komby/RFPix…SheidE1_31Transmitter.ino