Vixen LedTricks Frame data format? or Application method to drive Tricks-C w/o LTC_11

[stempile]

I am trying to figure out how to parse the Vixen .LED data. The XML file makes sense, but not knowing how the <Frame> data is written, it doesn't make sense.

Example:

        <Frame length="50">AABfAAEAXwACAF8AAwBfAAQAXwAFAF8ABgBfAAcAXwA=</Frame>
        <Frame length="50">AABeAAEAXgACAF4AAwBeAAQAXgAFAF4ABgBeAAcAXgAHAF8A</Frame>
        <Frame length="50">AABdAAEAXQACAF0AAwBdAAQAXQAFAF0ABgBdAAcAXQAHAF4ABwBfAA==</Frame>
        <Frame length="50">AABcAAEAXAACAFwAAwBcAAQAXAAFAFwABgBcAAcAXAAHAF0ABwBeAAcAXwA=</Frame>
        <Frame length="50">AABbAAEAWwACAFsAAwBbAAQAWwAFAFsABgBbAAcAWwAHAFwABwBdAAcAXgAHAF8A</Frame>

Objective: generate dynamic frame data files for then push out to LedTricks with Tricks-c using LTC_11.exe
1. An application will build a .LED file with frames
2. Application calls LTC_11.exe to drive out .LED frames

Ultimate Object: drive LedTricks with Tricks-c by pushing data directly through the serial connection.
1. An application will push frame data directly out to serial to Tricks-c


Anyone every tried this? I normally use LTC_11.exe to push a set of Vixen created frames. However my goal is to write an application that I can use to push out data in real-time, more of an interactive thing.

I reviewed the wiki and poked around in the forums, didn't find anything. Wasn't surprised because it already works great, I am just thinking about going in another direction...
Thanks!!
ms

[budude]

TimW would probably be your best source to help you. It's Base64 and some odd juggling of bits to put the Row/Column data in a 16-bit field (or something like that...). Somebody else here wrote a new image converter for LEDTriks - can't seem to find the posts but he might be a good source as well if you can find the posts.

[stempile]

hmmmm. I need to brunch up on parsing Base64, that helps. I will PM TimW and see what he has. Thanks.


I did some poking around in the LedTricksUtil.DLL.

There is a function "LoadFromXml(System.Xml.XmlNode)" and SaveToXml(System.Xml.XmlNode). I suspect that holds the answer.

I don't recall seeing KC post the non-compiled .DLL information in the past, has that changed? or perhaps I am just looking in the correct place.

[LabRat]

If your goal is to drive data direct to the TRIK-C, this seems a very round about route. The protocol for the serial communications has been published.

(trying to find a link.. which I know I had read previously, as it was used to create the PIX-C)
Oddly enough I can't find it at the moment. There is the source to the TRIKS-C , which can be used as a reference:

http://doityourselfchristmas.com/for...C-Firmware-V02
or the PIX-C code (backward compatible, with some extensions)
http://doityourselfchristmas.com/for...e=104&catid=22

<SYNC> <COMMAND> <PAYLOAD>

Note escape encoding for values 0x7D- 0x7F

List of commands are in the file, "blank, roll_left, roll_right, frame etc"

No need to muck about with XML parsers etc.

[stempile]

I agree with you! I started yesterday with trying to figure out what the <PAYLOAD> is by walking through both versions. Initially I was hoping there would be a way to pass a string to to Tricks-C, but then realized it was still LedTricks 'FRAME' based (back to the Vixen defined standard).

When sending serial data to Tricks-C appears to be Vixen 'FRAME' data. Not sure how the FRAME data is defined, so went back to the .LED files from Vixen. That landed me on to looking at the XML for the <FRAMES><FRAME> lines. At that point I didn't have anything left other then hope someone else has notes or a link I couldn't find...

I have looked around but can't find the protocol for how to define the <PAYLOAD>, or the Vixen LedTricks 'FRAME' definition, hope you can LabRat - it would help.

Thanks

[budude]

Duh - completely forgot about LabRat with his PIX-C - good source of info there for sure!

[stempile]

Still digging around, found this thread that was a conversation about a process to do text to LEDTRICKS frames.

[Aurbo99]

Last time I contacted TimW regarding the code for the Triks-C he informed me that the source would not be released. Perhaps he may lend some guidance in this.

On a similar note,

With some of the chips becoming obsolete, perhaps its time to take another look at building a new controller.

Triks-C to LedTriks to panel.
Pix-C to Ledtriks to panel.
The original Vixen based .Led files remained.

IF the 16x16 (Franks) panels make it back into production, perhaps a 16x16 single driver board cascading to each panel.


Something like a Atiny2313 to a pair of TLC5940's with a pair of quad darlington switches, data is passed along to each 2313 on each board.

Its not a new concept or design..

Do a search for "PEGGY-2" and if your lucky to find a copy of the PDF that provided the Schematic(they removed the schem on the 2.3 version), you'll see a very easy hack of this design from 25x25 down to 16x16.

[stempile]

Another example here.

[TimW]

I agree with you! I started yesterday with trying to figure out what the <PAYLOAD> is by walking through both versions. Initially I was hoping there would be a way to pass a string to to Tricks-C, but then realized it was still LedTricks 'FRAME' based (back to the Vixen defined standard).

When sending serial data to Tricks-C appears to be Vixen 'FRAME' data. Not sure how the FRAME data is defined, so went back to the .LED files from Vixen. That landed me on to looking at the XML for the <FRAMES><FRAME> lines. At that point I didn't have anything left other then hope someone else has notes or a link I couldn't find...

I have looked around but can't find the protocol for how to define the <PAYLOAD>, or the Vixen LedTricks 'FRAME' definition, hope you can LabRat - it would help.

Thanks

Hi Matt

I'm not sure why you don't go straight to the 'ultimate objective' and talk directly out the serial port to the triks-c/pix-c.

The command protocol is here

In terms of the 'payload'... its a bitmap of the panel, 96 bytes to represent 16 rows x 48 columns (768 bits). From memory it went bottom right back to top left in order but you'd need to check.

The 'FRAME' payload in Vixen .led XML is a different format. Each frame is a list of xy coordinates of on pixels, coded into base64. So the frame will be bigger or smaller depending on which pixels are on. The TriksC 'Payload' will always be the same size.

In LTC, I had to decode the frame string byte by byte, convert it back from base 64 and then load it into an array that could then be sent out using the LTC PAYLOAD. In modern languages this can be done with a couple of commands (see Greg Bartlett's VIXENXMLPARSER.pdf below for a class that does the same sort of thing for the Helix).

google "HowTo.Base64.pdf" for a good explanation of how it works. ... also see here

Hope that helps.

Tim