Picture of the first light of Cosmic Revelation at the KCETA inauguration, at november, 10th 2008, in front of the Audimax at the University of Karlsruhe
Picture of the first light of Cosmic Revelation at the KCETA inauguration, at november, 10th 2008, in front of the Audimax at the University of Karlsruhe
The users guide of the KASCADE-Grande TOR control Event Display application is here.
The artist Tim Otto Roth had the idea, to install 16 lights, each one representing a cluster of the
KASCADE array, and each light flashing immediately if one of the clusters exceeds a threshold in measurements. So the lights are an online visible representation of the
invisible cosmic ray particle showers reaching ground: "the cosmos reveals itself through the lights".
For the realization of the project, the existing
KASCADE array online event display written in the java programming language has been extended to control 16 stroboscopes via DMX commands, send over a
DMX interface of type USB-DMX-STAGE-PROFI-MK2 connected via USB/Virtual ComPort
to the controlling PC running windows (the USB-DMX-STAGE-PROFI-MK2 DMX interface
comes only with drivers for Windows). In principle, Linux should also be possible, as the USB chip is of the (to us) already known FTDI type).
The stroboscopes are of type "Showtec Jumbo Strobes DMX MKIII" from Showtec. As the strobes are supposed to flash only once on each trigger,
which is not forseen in the original firmware, we use a modified version of the open source (GPL) firmware written and published by Hendrik Hölscher.
This firmware offers 4 modes, including a single flash mode as desired.
The used stroboscopes are of type "Showtec Jumbo Strobes DMX MKIII" from Showtec. They have a power of 1500W, a flash rate of 1-12Hz
and an integrated DMX 512 interface with a possible address range of 0-511. The DMX channel corresponding to the address (set via DIP switches) corresponds to the rate, the
following channel is interpreted as intensity. Rate and intensity can also be set manually via two rotary switches.
With the original firmware, our desired single flash on each trigger could only be achieved by setting a specific rate and stopping the next flashes by setting rate back to zero,
but setting to zero has to wait, not to override the flash command at all.
To find a matching rate and the wait time is quite tricky and depends on the PC, the load and whatever. On the test PC a matching pair of values was found at rate=160 and wait time=1s.
Hendrik Hölscher has published an enhanced firmware for strobes, offering more control. WIth this firmware,
each strobes knows about three DMX channels: Rate and intensity as before, and in addition a mode.
Originally the Jumbo Strobe has not been supported by that firmware, but
Bernd Hoffmann
has managed to adopt it, so it works perfectly with the Jumbo Strobe DMX MKIII. The original microcontroller 89C51RA2BN by Philips is replaced by a compatible of
type ATMega8515-16PU by ATMEL with the adopted firmware. Only PIN 9, the reset Pin of the ATMega has to be turned up, cause defined inverse. In addition two
capacitors (33pF replaced by 12pF) of the clock crystal have been replaced on the Jumbo Strobe circuit board (board type: Shanguang-N P/N: 071030).
Here is a detailed description of the modes and their usage of the new firmware (thanks to Bernd Hoffmann):
Manual mode:
DIP-switch 10 = "on" => Manual mode.
DIP-switches 1-4 are responsible for the flash rate, with DIP-switch 1 corresponding to the slowest bit. If DIP switches 1-4 are off, the strobe is off.
DIP-switches 5-8 set the intensity, switch 5 is lowest, too.
DIP-switch 9 has no meaning in manual mode.
DMX mode:
DIP-Switch 10 = "off" => DMX mode.
DIP-switches 1-9 form the binary DMX address of the device. DIP-switch 1 is the bit with the lowest value, 9 has the highest value.
NOTE: The address 000 corresponds to DIP-switch 1=ON, that is 1! So the address maximum is 510, all DIP-switches=ON.
For our 16 strobes with channels ranges following each other, the address list looks like:
strobe - DMX address - DIP-switch setting
The additional 4 modes are:
Some notes about DMX, as it is something completely new to us:
DMX is a protocol used to control light and audio devices on stage. It is based on RS485, works with differential signals, supports long cable length and up to 512 addresses
to control as many devices (supposed each device consumes one channel). We worked with a cable length of one kilometer in lab, and 800 meters in the field, but needed a terminator
on the last strobe in the field!
As an interface between the java program and the strobes attached to the DMX cable, there is an
USB-DMX-STAGE-PROFI-MK2. It is connected to the USB port on PC side and to the DMX cable on the other and needs no additional power supply.
On first plugin, Windows (only windows driver are shipped) asks for an USB driver, which can be find on the shipped CD or in the folder of cosmic revelation. Path is
...\CosmicRevelation\dmx4all_cd\Drivers\USB-DMX-Interfaces\USB_Driver_2.00.00\Driver W2K-XP-Vista for a XP system. On installation a serial COM port is
provided, but it could also be directly addressed via USB. Only Windows drivers come with it, but there are also linux drivers for the used FTDI chip, but this was never tested in our case.
The interface supports two different modes for sending DMX signals:
Channels can be set separately via ASCII commands, sending a pair cannel/value for each channel. For example:
Another option is the block mode, which allows sending values to several channels at once, as one block of bytes:
The block is composed of:
The current state of all DMX channels is called the "universe", and is refreshed about 35 times per second from the controller. Our strobes (independant of firmware) always
check the state of the bytes corresponding to their address, but only do something on changes.
There is a XML file containing configuration options for the TOR control application. It is loaded and processed once at startup.
You can find here an example XML file.
Some settings can only be set via this file, others are available via GUI, too.
The file is divided in three "logical" parts:
The chapter general settings, their default settings and a brief explanation:
Out of these, only "auto_reconnect" can be set during runtime. Everything else can only be set via this file.
The chapter cluster settings, their default settings and a brief explanation:
These parameters can all be set during runtime and are valid immediateley
The chapter DMX settings, their default settings and a brief explanation:
Some of these can't be set during runtime: "pimpmystrobemode", "maxlimiter", "lightsteps" and "sleeptimebetweencmds" are only accessible via file. The others
can be set and are valid immediateley.
Derived from the KASCADE Online Display applet, the evt2dtor program is used as an application, due
to the access to the serial port and the file system. It should also be possible to use it as an applet with some accomodations, we never tried.
The byte code has been compiled with Java 6, so it is not compatible with previous virtual machines. There is no other limitation, and source could be
compiled with older JDKs without problems.
All resources (except JRE) are collected in one folder, so the class path can be kept short. With a batch file, the application is launched:
@ set CLASSPATH=.\commapi\comm.jar;.\jdom.jar;.\opera.jar;.\evt2dtor.jar
@ java -Xmx128 -Djava.library.path=.\commapi Evt2D.Evt2Dtor
The parameter -Xmx128 sets the maximum heap size of the virtual machine to a value of 128MB.
Option -Djava.library.path tells the commapi where to find the Dll to use for serial port access.
The used jars:
As the application connects via TCP/IP to the evt2d server socket and accesses the serial port, some java permissions must be granted. So find the java.policy file,
which is usually in the folder"JRE"/lib/security and add a section like:
grant codeBase "file:///c:/cosmicrevelation/-" {
permission java.security.AllPermission;
};
where to put the path with the batch file and jars (matching your setup). The "-" at the end, means, allow code from this directory AND all subdirectories.
Like with applet permissions, we never tried to find out the specific permissions but just granted AllPermission.
Applet versa application:
The application is an extension of the Event Display Applet, which was designed to run in a browser. For the COSMIC REVELATION project, it was extended as a java application,
mainly because of the use of the serial port. A first attempt to use serial communication from a browser failed due to missing permissions and the knowledge, how to set them.
"All permissions" for the source of the applet didn't work, nor some special ones. It should be possible.
Why Java 6:
There is no need for Java 6. It was just used, because of the ongoing java updates due to security problems. Unfortunately, the byte code is not backward compatible!
If desired, the source code could be compiled with an older version of JDK.
Connection problems:
The used (standard) Java sockets detect connection problems only on read or write attempts. Writing is not possible in our design, as the server expects no writes, defines
a write as an attack and disonnects. Detecting a read in the standard read mode is not easy, I use "bytesAvailable" on the InputStream, but there is no error at all!
Actually the connection problems are detected, if new data are missing after a certain timeout.
7. General notes/hints:
8. Known problems:
9. Version history:
07247/824702