Forum Index > Projects > LED Pegboard and Matrix Projects
 Peggy 2.3 problem: D16 to D24 are darker (updated)
 |  Printable Version
By: Windell (offline) on Thursday, April 22 2010 @ 12:10 AM PDT  
Windell

Okay, now, let's take it all the way:

Replace
SetPxSeq(i,j,k,w);

with

SetPx(i,j,15,15,15,15);

That should turn all the LEDs on, all the time.


Windell H. Oskay
drwho(at)evilmadscientist.com
http://www.evilmadscientist.com/

Forum Evil Scientist
Evil Scientist

Status: offline

Registered: 06/15/06
Posts: 1932
Sunnyvale, CA

Profile Email Website  
   
By: Anonymous: project2501 () on Thursday, April 22 2010 @ 01:01 AM PDT  
Anonymous: project2501

Replaced

SetPxSeq(i,j,k,w);

with

SetPx(i,j,15,15,15,15);

The board lights up uniformly with no apparent issues.





       
   
By: Windell (offline) on Thursday, April 22 2010 @ 01:22 AM PDT  
Windell

Well, that certainly does make it seem like there's some sort of software issue... and a proof of principle (but crappy) solution.

I wonder if there's something funny in the compiler optimizations that is screwing with the order of operations... still not sure of the exact mechanism.

Are you using Arduino 0018? (If not, you should be.)

If you're still game to try a few more stabs in the dark, please try opening up the Peggy2.cpp file in the library and editing it. Inside Peggy2::RefreshAll, look for the part where it says:

PHP Formatted Code
      SPI_TX(mix.c[3]);
      SPI_TX(mix.c[2]);
      SPI_TX(mix.c[1]);

      PORTD = 0;  // Turn displays off

      SPI_TX(mix.c[0]);



and try replacing that by

PHP Formatted Code
     
      PORTD = 0;  // Turn displays off
      SPI_TX(mix.c[3]);
      SPI_TX(mix.c[2]);
      SPI_TX(mix.c[1]);
      SPI_TX(mix.c[0]);
      asm("nop");
 



In other words, turn the display off *before* sending out those four lines, and add an extra delay at the end. Then, run one of the normal sketches to see what effect this has.

Thanks for your help in getting to the bottom of this!


Windell H. Oskay
drwho(at)evilmadscientist.com
http://www.evilmadscientist.com/

Forum Evil Scientist
Evil Scientist

Status: offline

Registered: 06/15/06
Posts: 1932
Sunnyvale, CA

Profile Email Website  
   
By: Anonymous: project2501 () on Thursday, April 22 2010 @ 01:59 AM PDT  
Anonymous: project2501

I have been using Arduino0018 with the "Aruduino Duemilanove or Nano w/ ATmega328" board selected.

Changing that code in Peggy2.cpp didn't seem to have any effect, unfortunately....

Actually, with both the standard and modified code, the board seems to be getting worse over time. Instead of just six rows experiencing the behaviour, there are about 10 to 12 now.

And thank you for helping out, I will do whatever it takes to get it operating correctly Big Grin





       
   
By: Windell (offline) on Thursday, April 22 2010 @ 02:14 AM PDT  
Windell

>Changing that code in Peggy2.cpp didn't seem to have any effect, unfortunately....

A stab in the dark, as I said...

Actually, with both the standard and modified code, the board seems to be getting worse over time. Instead of just six rows experiencing the behaviour, there are about 10 to 12 now.



Well that is interesting. Are you still running off of battery power? Might try (briefly) switching in a new set of alkaline D cells to see if the power supply is sagging.


Windell H. Oskay
drwho(at)evilmadscientist.com
http://www.evilmadscientist.com/

Forum Evil Scientist
Evil Scientist

Status: offline

Registered: 06/15/06
Posts: 1932
Sunnyvale, CA

Profile Email Website  
   
By: Anonymous: project2501 () on Thursday, April 22 2010 @ 02:35 AM PDT  
Anonymous: project2501

Actually, the worse results were with new batteries, but I now switched back to the old batteries and I got better results. Now after running the old batteries for a few minutes though, I'm getting the same results as the new batteries. I then switched to a third set and still get the same results, and now I get the same results on all batteries now no matter how many times I switch them.

I need some sleep, so I will let the system sit with no batteries in it overnight and I will try it again tomorrow.

Something certainly is odd, that is for sure....Neutral





       
   
By: Anonymous: project2501 () on Thursday, April 22 2010 @ 09:58 AM PDT  
Anonymous: project2501

I put in the batteries again this morning and it is still the same...

If there are no visible issues when running the RGB program, can we absolutely rule out a soldering issue? Or might there be a bad solder connection somewhere?





       
   
By: Windell (offline) on Thursday, April 22 2010 @ 10:27 AM PDT  
Windell

>I put in the batteries again this morning and it is still the same...

At least it's consistent. Big Grin

>If there are no visible issues when running the RGB program,
>can we absolutely rule out a soldering issue?
>Or might there be a bad solder connection somewhere?

I had *mostly* ruled that out from the beginning. A single bad solder joint can take out a half row or whole column. However, what you have is an intermittent flakiness associated with one half row controlled by chip U5. There are certain unlikely assembly issues that could possibly cause something like this.

Check U5 carefully-- especially to make sure that all of the socket pins poke all the way through the board on the bottom side, and that viewing the socket from the top (chip still in place) the little metal socket bits are all seated properly in place. Check the soldering there on the bottom, especially on the lower-left corner, and if there's any room to see under the socket, see if anything looks amiss. Also check that the chip is fully seated in the socket.


One more code-based thing to try in Peggy2.cpp: try a slower refresh.

Inside Peggy2::RefreshAll, find the part where it says

while (i < 50) {
asm("nop" );

and change that 50 to a 500. That will slow down the refresh rate to by a factor of 10. Then try a factor of 5000 and see what happens.


Windell H. Oskay
drwho(at)evilmadscientist.com
http://www.evilmadscientist.com/

Forum Evil Scientist
Evil Scientist

Status: offline

Registered: 06/15/06
Posts: 1932
Sunnyvale, CA

Profile Email Website  
   
By: Anonymous: project2501 () on Thursday, April 22 2010 @ 05:14 PM PDT  
Anonymous: project2501

Still no change with i < 500 or 5000... The display flickers a lot now, but it still doesn't draw the parts of those rows.





       
   
By: Windell (offline) on Friday, April 23 2010 @ 11:04 AM PDT  
Windell

Okay. Next, let's see if the order of operations matters. What I'd like to do is change the order of row scanning from top-to-bottom to bottom-to-top. In doing so, will the problem move from the rows close to the top to the rows close to the bottom? (If the problem is purely software, I expect that it would.)


PHP Formatted Code

void Peggy2::RefreshAll(unsigned int refreshNum)
{
  unsigned int i,k;
  char j;

  union mix_t {
    unsigned long atemp;
    unsigned char c[4];
  } mix;

  k = 0;

  while (k != refreshNum)
  {
    k++;

    j = 24;
    while (j >= 0)
    {
      if (j == 0)
        PORTD = 160;
      else if (j < 16)
        PORTD = j;
      else
        PORTD = (j - 15) << 4;

      i = 0;
      while (i < 50) {
        asm("nop");
        i++;
      }

      mix.atemp = buffer[j];

      SPI_TX(mix.c[3]);
      SPI_TX(mix.c[2]);
      SPI_TX(mix.c[1]);

      PORTD = 0;  // Turn displays off

      SPI_TX(mix.c[0]);
      PORTB |= 2U;    //Latch Pulse
      PORTB &= 253U;

      j--;
    }

  }
}


 



Note: this code is experimental and untested and may do funny things at the top and/or bottom row.


Windell H. Oskay
drwho(at)evilmadscientist.com
http://www.evilmadscientist.com/

Forum Evil Scientist
Evil Scientist

Status: offline

Registered: 06/15/06
Posts: 1932
Sunnyvale, CA

Profile Email Website  
   
By: Anonymous: project2501 () on Sunday, April 25 2010 @ 02:38 AM PDT  
Anonymous: project2501

I tried the new code and it shifted the problem "2 rows up", so that that a single line on the bottom experiences issues, and still many of the same rows in the top right experience issues. Also, it draws the lines temporarily while on that certain line instead of not drawing them like before.

It's kind of hard to explain so I made a short video:
http://www.sendspace.com/file/wo5jkz

I'm still using the peggy2_firstdemo program for all of my testing.





       
   
By: Windell (offline) on Sunday, April 25 2010 @ 03:48 AM PDT  
Windell

Well, that's interesting and somewhat unfortunate-- that makes it sound like it's more of a hardware problem again. I'm going to have to try some tests on a Peggy here and get back to you with additional software tests to try. Please also contact me off-forum by e-mail; I may have a couple of other suggestions in the mean time.

If anyone else is experiencing these symptoms please do let me know as well-- I'd like to get to the bottom of this.


Windell H. Oskay
drwho(at)evilmadscientist.com
http://www.evilmadscientist.com/

Forum Evil Scientist
Evil Scientist

Status: offline

Registered: 06/15/06
Posts: 1932
Sunnyvale, CA

Profile Email Website  
   
By: Anonymous: tof () on Wednesday, May 26 2010 @ 06:09 AM PDT  
Anonymous: tof

Hi, I am experiencing the same problem with Peggy 2.3 and white LEDs.

I ran some tests with Peggy 2.3 configured in Serial mode and loaded with the PeggySerial>RecvSerial Arduino code.

When the RecvSerial starts, there is some flickering in LEDs D216 through D224.

If I send data to dim all the LEDs through 16 brightness levels (0 to 15) over a period of 8 seconds, I see problems in all the LEDs inside the rectangle determined by LEDs D116 (top left corrner) and D1424 (bottom right corner). Some rows turn on* only once a certain brightness level is reached and other rows simply never turn on*.

If I turn all LEDs to their maximum brightness (brightness level 15) and leave them on for a minute all LEDS (except D716 to D724 that still flickers) eventually turn on* with maximum brightness (the problematic rows turn on* one by one gradually). After 5 minutes, D716 through D724 eventually turns on.

*: in this context, turning on means reaching the same brightness as the other "working" LEDs.





       
   
By: Windell (offline) on Wednesday, May 26 2010 @ 09:41 AM PDT  
Windell

Hi tof,
I'm sorry to hear about the trouble. I think that this is our first report of this problem (1) using white LEDs and (2) using the serial option.

In the previous report, we had the following configuration:

Peggy 2.3 / P2 option
Battery power
STP16CPS05 chips
Standard "Peggy2" library or derivative programs
Yellow LEDs



Now, you have the serial option and white LEDs. The serial option means that different rows are affected, but are ultimately acting similarly. Can you say which power supply you are using and exactly which driver chips you have?

Last week I was able to personally look at someone else's board that was reporting these problems, but I failed to get it to misbehave in my presence. Frown

If I can get my hands on one that's acting this way, I should be able to finally nail this. Otherwise, please keep feeding me hints, and I'll see what I can do.


Windell H. Oskay
drwho(at)evilmadscientist.com
http://www.evilmadscientist.com/

Forum Evil Scientist
Evil Scientist

Status: offline

Registered: 06/15/06
Posts: 1932
Sunnyvale, CA

Profile Email Website  
   
By: tof (offline) on Wednesday, May 26 2010 @ 10:50 AM PDT  
tof

Hi Windell,

I "augmented" my Peggy 2 with four female headers (see picture) so I can switch between standard or serial modes quickly. I can run tests either way.





My board configuration:

  • Peggy 2.3 ( I do not know what is the P2 option)
  • Serial mode & non serial mode
  • STP16CPS05 chips
  • Standard "Peggy2" library or derivative programs & RecvSerial
  • White LEDs



Ok, this is strange. I used to run my tests with the Evil Mad Science 5V power supply, but I just popped in some batteries instead. All the LEDs now behave properly.


Forum Apprentice
Apprentice


Status: offline

Registered: 05/26/10
Posts: 2

Profile Email    
   



 All times are PDT. The time is now 11:50 PM.
Normal Topic Normal Topic
Locked Topic Locked Topic
Sticky Topic Sticky Topic
New Post New Post
Sticky Topic W/ New Post Sticky Topic W/ New Post
Locked Topic W/ New Post Locked Topic W/ New Post
View Anonymous Posts 
Able to Post 
Filtered HTML Allowed 
Censored Content 

Evil Mad Scientist Forum Archives — Read only!

Please visit our new forums for new discussions.


DIY Hardware for Electronic Art


The Original Egg-Bot Kit


Octolively
Interactive LED kits


Meggy Jr RGB
LED matrix game
development kit.


Business-card sized
AVR target boards


Peggy 2
LED Pegboard kits

My Account






Lost your password?