GrandMA Command Line Interface

[Update 16.11.2017] Due to request there is an updated Version of this post [/Update]

[Update 20.10.2016] This seems to be quite an active post on this website according to the wp statistics plugin. If you are a real human being (and not a clever bot) please leave a comment below so I can see whether there are real people searching for this topic. Best regards, Andy [/Update]

 

I had this lying around for years – literally.

 

(The following pieces of information might be outdated…some of the things are recovered from my memory  – some are leftovers from handwritten documentation I made while analyzing the software. The first working version of the code dates back to the beginning of 2008…. but I did a quick check and all of the things still do work so I can’t be that wrong.)

 

I have been doing lights for concerts, disco and various parties throughout the years. Most of the times I used a GrandMA lighting desk. Either a real hardware console or the cheaper onPC version.

A few years ago there was an additional software for PocketPC which gave you the possibility to control the GrandMA desk via a PocketPC.

i never owned one of theses but fortunately you could get the GrandMA PocketPC Emulator officially for free which let you use the the software via an ordinary pc.

 

However, in my eyes there is/ was little to no use for this software on a pc since the software also emulated the PockePC’s actual screensize and a huge amount of the PC’s screen estate was wasted and so the software was no fun to use at all. If you wanted to control a GrandMA console via PC you could better have started the onPC version and join a network. That way you’d have roughly the same look’n feel and could use the complete computerscreen.

 

 

Cool thing: The console, as well as the PocketPC software, offers a commandline. So instead of clicking a button or moving a fader you could do a complete show just by typing ‘fader 1 at 100’ or ‘off fader 4.1’ or … This feature is extremely useful when you are programming a show and the proper usage of the command line can save you lots of …mouse-kilometers …

 

That made me very curious and I decided to build my own remote solution for the GrandMA console.

 

Due to the fact that everything was handled via network it was easy to listen to the communication between the programs just by using wireshark. That’s what I did.

 

 

One thing that really made me wonder when I started sniffing was the huge amount of unexplainable traffic between the PockePC software and the lighting desk. nothing was happening but there was a steady flow of data.

I took me quite a few minutes to realize and still makes me wonder today:

Instead of transmitting button codes (e.g. button ‘1’ pressed, button ‘highlight’ pressed) the developers transmitted the motion of the mouse within the software (most of the times). So when you moved the cursor over the PocketPC interface every time the new position of the cursor was transmitted to the console. When you clicked a button the ‘click’ was transmitted (actually the ‘click’ and the release of the mouse were transmitted independently) and the console – due to knowing the absolute position of the mouse – was aware of the button you just clicked.

 

(During my various research projects with the GrandMA console I came across a lot of things that I could never understand. Neither from a perspective on stability, nor from a security-orientated point of view, but that’s another story.)

 

There are a few exceptions from this rule. The ‘Clear’-button, for example always sends a fixed command string.

When the button is pressed the console receives this command:

0x02, 0x04, 0x04, 0x01, 0xCE, 0x00, 0x20, 0x00

 

And when the ‘Clear’ -button is released it sends

0x02, 0x01, 0x02, 0x00, 0xCE, 0x00, 0x20, 0x00

 

The famous ‘Oops’-button, however, is always transmitted by

0x00, 0x87, 0x00, 0x4d, 0x00.

 

The rest is more or less a matter of patience and observation (the art of using wireshark lies in the skill to filter the unnecessary things that only distract you)  but in the end it all comes down to 3 network ports being used:

 

The commands themselves are transmitted via udp port 7001.

A connection to port 7002 (udp) has to be made in order for graphics to be transmitted. It’s just consequent from the developers to not only transmit the movement of the mouse from the pocketPC to the console, but also to transmit the blinking cursor from the console the the PocketPC.

We are not talking about ‘cursor ON’ – ‘cursor OFF’ messages … we are talking about the complete cursordata (every single pixel of the blinking cursor) being transmitted EVERY time …   ALL the time.  … wtf?

I didn’t use this feature in my software but you need to establish the connection in order to get the connection to the console working.

At the end we need port 7003 (udp – you guessed it) to handle the initial logon with username and password. I hardcoded the username ‘andy’ without a password.

 

 

See this video to get a glimpse of the functionality (best thing is to switch to 720p fullscreen to be able to see the details)

[tube]http://www.youtube.com/watch?v=vXMf1L0wQ44&feature=youtu.be, 888, 500[/tube]

 

My original plan was to make my software more of a middleware so I could control a lighting desk over ethernet via ….anything. Or get deeper control over the console via a MIDI to CMDLine-converter, or …      But like with most projects I found other solutions and I kind of forgot about this.

 

Later I wasn’t sure about publishing it because I was way too afraid of legal problems but I recently had a talk with the creators of the console (greetings!) and they ensured me that it wouldn’t cause me any trouble.

I also think that it’s a rather safe deal since the console has undergone some major updates and now offers a telnet prompt natively.