Go Down

Topic: ShiftMatrix, Dreaming Big Video Display (Read 10 times) previous topic - next topic


Code: [Select]

if (byteToRead == '~'){ //is it "~" start the frame
      outPWM = 0;
      ShiftMatrixPWM.m_PWMValues[outPWM] = byteToRead ;

So what happens when one or more of the 256 PWM values is the same as the ASCII value of '~'?
Send Bitcoin tips to: 1L3CTDoTgrXNA5WyF77uWqt4gUdye9mezN
Send Litecoin tips to : LVtpaq6JgJAZwvnVq3ftVeHafWkcpmuR1e


I am sending one start byte. Then I am sending the whole frame array in one command. I am not currently using an end byte, that may change in future.

I have not seen any buffering issues. I'm not an expert but from what I can tell the micro is running much faster than the baud rate of the serial. When a byte comes into the serial buffer my routine runs very quickly and finishes well before another byte even gets to the buffer. I actually made that mistake when I first tried to make this. I was detecting when the first byte arrived and then telling it to get all the frame bytes in a for loop. This didn't work. I did some debugging and finally realized that I was getting the first byte but all the other Serial.reads were not getting anything. Then it hit me. The micro is running at 16Mhz or 16 000 000hz where the serial data is coming in at (in my tests) 115 200hz. That is 138 times slower than the micro. So instead of a for loop to fill the array I changed to a counter being increased (outPWM). So now it detects a byte has arrived. Checks if it is the start byte. If yes it resets the counter and then exits the Serial.available if statement. If its not the start bit, it puts the byte into the library's PWM array, using the counter to keep track of which array position should be filled. Then again exits the Serial.available if statement.

I have no error checking or qualifying. It expects to be sent the correct data in the right format. When I test going modular with this I will be changing this slightly. I will probably put another if statement in to check if the counter is above the maximum number of pixels. Therefore it will do nothing with the byte that is read.

About the start byte. The values I am using at the moment for PWM are 0-31. '~' is value 126. So it is not possible for a frame value to be the same. If you wanted to have 0-255 I would suggest modifying a 255 value to be 254 and then use 255 as a start byte. But thats just one way you could do it. :)

I hope the above all makes sense. :)


I am waiting for my RGB matrix order to arrive and have been doing some more testing. Using the ShiftMatrix library you can actually get control of up to 1024 individual LED's. Out of the two configurations 64*16 is the best as it allows 32 levels of brightness. And with 16 rows the LED's still look nice and bright.

I am now wondering what would look better? By making these modular as I was looking at doing, I could make a 64x64 Mono color matrix with just 4 Arduino's and quite a number of shift registers. Or do I continue and go color with a 32x32 RGB matrix?

What are your opinions, "Color over more dots" or "more dots over color"? Which do you think is more important when looking at a down scaled video? The final matrix is meant to be an outside display as part of a Christmas feature. So it will be big and viewed from a distance. This is the hope at least. I am starting to think I am not going to have it together in time.  :smiley-eek-blue:


I would go for color over resolution but as you need it for christmas i'd say go with mono red or green as it fits the theme. Also i would do some testing with the LED distance and the distance you want to look at it from.


Well it has taken a long time for my colour matrix parts to arrive but I have it up and running. Initial tests were very disappointing. Colour was extremely washed out and very hard to make anything out. I ran test patterns which showed that all the LED's were functioning as expected in the matrix. So I did some reading about outputing colours on an RGB LED and learnt some more about how the human eye responds to light. Long and the short of it was that the linear application of colour from the Processing script was messing things up (i.e. the 0-255 levels). I was simply dividing by 8 to get 0-31 brightness levels. This did not translate well on the Matrix and looked TERRIBLE! After some googling I found this "INT(31^(LEVEL/31)+0.5)", it takes the original 0-31 brightness value and translates those levels into better levels for our eyes to identify. Using this has dramictally improved the picture on the Matrix. Colours look much clearer and closer to what I would expect to see.

Unfortunately all this waiting for parts (and other outside forces) have delayed the project and I don't think I will be able to complete it in time for Christmas. I am disappointed but I will be continuing on, in the blind hope I might get something ready. After all my tests I am going to go with Mono Green at 64x64 resolution with 32 brightness levels. This will be using four 16x64 modules. I see much soldering in my future. Mono colour seems to be easier to build and cheaper to source. Even at 16x16 in color I found the picture very hard to make out. And the colour version I was planning was only going to be 32x32. I am hoping that better resolution will make up for the lack of colour.

Let me know what you guys think.

Go Up