Glediator ouput options problem using a Nano and WS2812b strips

Hello, I have a project where I have a matrix of WS2812b strips that are laid out in a 20 x 15 grid. Currently the the first led is on the bottom right and number 15 is at the top right and it is in a serpentine layout going from right to left. I've recorded different animations in Glediator and then onto a micro sd card and I'm using an Adafruit micro sd breakout board. Although the recorded animation is displayed on the matrix I made (incorrectly), no matter what what options I select or change in the output options window, the animation is unaffected. Anyone know what I'm doing wrong? Thanks in advance.

Anyone know what I'm doing wrong?

I think people will struggle to know what you are doing, let alone doing wrong.

no matter what what options I select or change in the output options

So what are these options then?

It should be a simple matter to change the LED numbers with a bit of simple arithmetic.

Right there in line 34, or that is what my crystal ball tells me. Your real code might be different, who knows, you haven't posted it.
Before you do, find out how to do it correctly by reading this:-
How to use this forum

I guess it’s pretty obvious that I’ve never posted in a forum before. Thanks for the tip. So here’s the sketch:

// Glediator Arduino UNO sketch by Jens Andrée /
// 500k bauds with 80 pixels no problem
// sdcard stream for stand-alone operation.
// changed to WS2811 chip and a few small changes by Nils Gregersen /

#include <FastLED.h>
#include <SPI.h>
#include <SD.h>

#define NUM_LEDS 150
#define DATA_PIN 6
#define CHIPSET WS2811
#define CMD_NEW_DATA 1
#define BAUD_RATE 115200

File fxdata;

void setup()
  FastLED.addLeds<CHIPSET, DATA_PIN>(leds, NUM_LEDS); //see doc for different LED strips

  for(int y = 0 ; y < NUM_LEDS ; y++) 
    leds[y] = CRGB::Black; // set all leds to black during setup

  pinMode(10, OUTPUT); // CS/SS pin as output for SD library to work.
  digitalWrite(10, HIGH); // workaround for sdcard failed error...

  if (!SD.begin(10))
    Serial.println("sdcard initialization failed!");
  Serial.println("sdcard initialization done.");
  // test file open
  fxdata ="myanim.dat");  // read only
  if (fxdata)
    Serial.println("file open ok");      

int serialGlediator ()
  while (!Serial.available()) {}

void loop()

  fxdata ="myanim.dat");  // read only
  if (fxdata)
      Serial.println("file open ok");      

  while (fxdata.available()) 
    fxdata.readBytes((char*)leds, NUM_LEDS*3);;
    delay(50); // set the speed of the animation. 20 is appx ~ 500k bauds
  // close the file in order to prevent hanging IO or similar throughout time

And here’s the layout (10 vertical strips of 15 leds in each):

136135 ~ 1615
| | | |
| | | |
150 121 ← ~ ← 30 1
Data in

I’m able to record animations in Glediator and save it onto the micro sd card as ‘myanim.dat’ just fine and the Arduino reads the data file fine and displays it on the matrix, but incorrectly. The colors and layout don’t match what is in the preview window of Glediator. In the output options I’m able to change things like the mapping mode, ie. Single Pixels or Board of Pixel, the pixel order, ie. HS_TL, HS_BR, VS_TL, VL_BL, etc., the colour order, ie. RGB, GRB, GBR, etc… After I’ve made a change in the output options, pressed ‘apply changes’, record, essentially, the same animation onto the micro sd card and then try to play it on my matrix, none of the options I’ve changed affect the animation. I’ve been testing it out on a 10 x 15 matrix instead of my original 20 x 15.

Thanks for the extra information.

You have a complex system so what you have to do is to break it down and see where it is going wrong.

Start simply, have a data set that consists of simply of one red LED being on in the top corner. See what that produces.
Is there just one LED on? What colour is it? Where is it?
If the position or colour does not change with any of those options then that bit of the system is not working.

The idea is that you can come up with a simple few lines of code that will unscramble your pattern that the system produced so as to match the pattern you want. This is not as difficult as it sounds, but let's start simply with something we can understand and interprete simply.

Right I have downloaded this application and it is not what I thought it was. I thought it was to create your own images where as in fact it is just to put pre-programmed pattern sequences together, as far as I can see.

You said:-

I've recorded different animations in Glediator and then onto a micro sd card

How have you done that? The two sorts of files I have managed to save are not in the format that the code you have can use. The files are mainly text messages for the application itself.
This is what I saved when I just set up a black pattern:-

#Wed Jun 15 10:54:08 BST 2016

This is not data that the fast LED libiary can use to the best of my knowledge. The value of -1677721 for the RGB translates into the hex value 0x1000000 which could be interpreted as black, but the other stuff is nonsense as far as pixel definitions are concerned.

If you are pushing that into your matrix no wonder it is coming out a bit random.

Now I could be saving the patterns wrong but I can only see two save options, one for the project and one for the sequence, it is the latter I have shown here although the former was not much different.

Yeah, I had to play around with the application for a while to figure out how to use it. Not exactly the most intuitive application. The author doesn't have a users manual for it just yet.

So basically you create whatever patterns you want in the left and right window and then you can fade them in and out of one another and the sequence that you'll be recording is in the center window. To start recording, go to 'extras' -> 'recorder' -> 'rec' and then you'll be prompted to save the recording. I save it as, 'myanim.dat', same as in the sketch. Then you'll see the number of frames and kbs it's recording and when you press stop, voila! A 'myanim.dat' file is created.

I've saved a few different animations under different names and when I load them up again and play them in Glediator, they look fine, but when I transfer them onto the sd card and then try to play it on my matrix, it doesn't match up with the animation in Glediator. When I play the single diamond pattern, the colors are inverted and it displays the diamond animation like this:

/ \ /
/ /
\ /
\ /

instead of this:

/ \
\ /
\ /

Essentially showing 1 and a 1/3 of another diamond.

When I play the horizontal rainbow pattern, every odd strip, the colors are flowing in the opposite direction.

When I go to 'Options' -> 'Output', make any changes (ie. Mapping Mode, Pixel Order, Board Order), press 'apply changes' and then make another recording, none of the changes I've made is saved onto the new 'myanim.dat' file. I've tried every option. I've watched the tutorial video for Glediator with an sd card a few of times, on Youtube, to see if I missed anything. It seems like the changes made in the output options are suppose to be saved onto the sd card.

Thanks I did manage to get a file of the pattern

To start recording, go to 'extras' -> 'recorder' -> 'rec' and then you'll be prompted to save the recording.

What a stupid name, record implies taking a record of something not storing something. I could not get the save on SD card to run.

So basically you create whatever patterns you want in the left and right window

But is that not only from the pre programmed pattern generators and you only have access to some parametric controls of that pattern generator. Am I right in thinking you can not generate your own pattern with just one LED on and all the others off?

The pattern files are simply a list of the values of all the LED values, so not very clever. But without the ability to make a simple pattern you can't tell if the serpentine raster adjustment bit is working.

The matrix size at both ends has to be the same, there is nothing to enforce that. It sounds like that is not the case with your pattern, can you double check that.

Once we know the actual mapping it produces then it should be easy to adjust it to the way you have wired up your matrix.

The author doesn't have a users manual for it just yet.

It would seem that he never had one for any version so I wouldn't hold your breath waiting for one.

I chatted with the software author and he told that there's a bug in the software that doesn't allow the output options to be saved onto the 'myanim.dat. He said he wants to work on it, but no firm date. I also chatted with the sketch author and he helped me out with the strip layout because we were unable to change that in the software and then have it transfer onto the sd card.

The only issues I'm having now are that the patterns are now rotated 90 degrees and the color order is still wrong. It doesn't make much difference, visually, for most of the patterns, but things like my animated gifs and captured video have to be rotated and color adjusted before I record them in Glediator. It's a bit of a pain in the ass to do, but at least it works and looks great on my project! Thanks for the effort. really appreciate it.

Ok that is still the sort of thing we can fix in software at the Arduino end. How have you got your strip wired up as a matrix now?

Yeah, currently it's setup in a 15 x 12 matrix in going right left right left.

Yes but do the strips run up or across and is it still a serpentine raster?
Do you know how you need to swap the colours? Like is it red for green? Or do all three need swapping arround?

So the strips are setup on my vest vertically as shown below and since I can't save the pixel order I set in Glediator onto the sd card, the image on my matrix is 90 degrees counter clockwise. So basically in order for the image on my vest to match what's in the preview window in Glediator, I would have to rotate my matrix 90 degrees clockwise. This isn't actually a big deal, because I'm mostly just displaying patterns. You would only notice it if I was displaying text or animated gifs

As for the colors, red and green have to be swapped and blue is fine.

15 30 165 180
| | | |
| | ~ | |
| | | |
1 16 151 166

OK let's see what I can come up with in software.

This is difficult because I can’t get your code to compile, you seem to be using a different SD libiary. I am using Arduino 1.6.9.

Anyway try replacing your loop function with this, it should swap your red and green colours. If not try changing the order of the variables in the led line.
*void loop()
byte r,g,b;
  fxdata =“myanim.dat”);  // read only
  if (fxdata)
      Serial.println(“file open ok”);   

while (fxdata.available())
  { for(int i=0; i< NUM_LEDS; i++) {
    leds[i] = CHSV(g,b,r);
    delay(50); // set the speed of the animation. 20 is appx ~ 500k bauds

// close the file in order to prevent hanging IO or similar throughout time
If that works let me know and I will try for the rotation.

Grumpy is helping you solve the grb /rgb order, and then you'd need to remap the pixel strips either in that software or on your arduino.

I'm developing FAB_LED on github, a library that handles all those issues for AVR CPUs because I encountered them. If you defined a remapping array with it, it would convert on the fly any new pattern you load.

I'll have to play with glediator too, looks cool :stuck_out_tongue:

then you'd need to remap the pixel strips either in that software or on your arduino.

That is the next step when he gets back to me.

I'll have to play with glediator too, looks cool

While it might look cool it is restricted to pre programed patterns and a lot of the features don't work. Even the write to file function that the OP is using often produces just a file full of zeros.

Any link to your stuff?

I was being lazy and not link...

That's the LED library. I'm currently coding the "draw" branch where i'm simplifying the user API.
3-wire LEDs are supported, apa102 is not fully supported (aka untested), and AVR > 16mhz
is supported, but not ARM yet (aka untested and likely totally broken).
On the plus side I support update of up to 6 LED strips in parallel at 16mhz. :stuck_out_tongue:

I also have a branch with an update to attiny definitions to support 16mhz, waiting for it to merge
to the main repository.

with FAB_LED, for this case, the API call would be:

#include <FAB_LED.h>

ws2812b<D,6> strip; // uses port D6
rgb leds[NUM_LEDS];
const uint8_t * remap = { 32, 31,… }

fxdata.readBytes((char*)leds, NUM_LEDS*3);

//strip.draw(uint16_t count, pixelType * array, uint8_t * map)
strip.draw(NUM_LEDS, leds, remap);

Here two things would happen:

  • the array is rgb, but ws2812b is grb, so draw() would handle the conversion. It’s a tad slower.
  • the remap would fetch the pixels from the leds array in the order of the LED strip. remap is in the order of the LED strip, and holds the index of the pixel in leds

Note: strip does not use any pixel buffer, it only uses the array you pass it so there’s zero memory overhead.

15*12 pixels = 180, but yet you have NUMLEDS set to 150 ?

Hey guys. Sorry, I’m not ignoring you. I’m just in the middle of moving and I’m hoping to unpack my computer and all the electronics tomorrow.