LED Matrix help

[Jon]

Well, there is definitely somethig strange happening here.

I set up the code for sending the data manually.

First line is the serial data I send, (serialdata(39) => serialdata(0))
Second line is status of pins, (1=LED On, 0= LED off)


.U1('595)........U2...........U4............U5...........U6
11111111 00000000 00000000 00000000 00000001
11111111 00000000 00000000 00000000 00000000

11111111 00000000 00000000 00000000 00000011
11111111 00000000 00000000 00000000 00000001

11111111 00000000 00000000 00000000 00000111
11111111 00000000 00000000 00000000 00000011

11111111 00000000 00000000 00000000 00001111
11111111 00000000 00000000 00000000 00000111

pattern repeats to

11111111 00111111 11111111 11111111 11111111
11111111 00011111 11111111 11111111 11111111

11111111 01111111 11111111 11111111 11111111
11111111 00111111 11111111 11111111 11111111

So we appear to be one pin out.
but,

11111111 11111111 11111111 11111111 11111111
11111111 11111111 11111111 11111111 11111111


If I run the opposite way.....

11111111 10000000 00000000 00000000 00000000
11111111 10000000 00000000 00000000 00000000

11111111 11000000 00000000 00000000 00000000
11111111 11000000 00000000 00000000 00000000

11111111 11100000 00000000 00000000 00000000
11111111 11100000 00000000 00000000 00000000

pattern repeats to

11111111 11111111 11111111 11111111 11111100
11111111 11111111 11111111 11111111 11111100

11111111 11111111 11111111 11111111 11111110
11111111 11111111 11111111 11111111 11111110

11111111 11111111 11111111 11111111 11111110
11111111 11111111 11111111 11111111 11111110

11111111 11111111 11111111 11111111 11111111
11111111 11111111 11111111 11111111 11111111

All Works fine.

Now, if I start sending 'random' 1's and 0's to the MIC5821's
11111111 11110011 11000011 11110111 01110110
11111111 11110001 11000001 11110011 00110010

11111111 01110001 11001011 11110111 00110100
11111111 00110000 11000001 11110011 00010000


Gee, if I was confused before I started this...............

One other thing,
Using this method, the LED's are much brighter, how I would expect them to be. The multiplexing, must (understandably) be causing them to appear a little less bright.

Oh, and for the one from the sample code.......

11111111 10000000 10000000 10000000 10000000
11111111 10000000 00000000 00000000 00000000

[Guido Körber]

Now this is totally strange.

I will see about setting up the exact same circuit here in the next days.

The thing with the brightness: Multiplexing is done in a 1:8 ratio, so each LED is on only for 1/8 of the time resulting in also only 1/8 of the light being emitted.

[Jon]

Your help is most appreciated.

[wayoda]

Hi,
here's an idea from CSI-DownUnder :)

Looks like we have two theories here :
1) The data gets shifted one step too far so the last value gets pushed over the edge!

2) Some kind of weird animal is hiding under the ic-sockets on your board an whenever it sees a group of 1's coming along, it hits the last one in the group over the head and eats it. This would explain why a single 1 like in
[11111111 10000000 10000000 10000000 10000000] disappears completly.

The prove the second theory could you please try the following data:
[11111111 00000110 00000110 00000110 00000110]

I would expect the ouput to be
[11111111 00000010 00000010 00000010 00000010]
Which would tell us two things:
Theory 1 is wrong because the position of the 1 in the output can only be reached if the correct number if shift-ops took place,
Theory 2 has something to it.

Now, weird problems, weird ideas:
If you ask me what kind of animal from the world of electronics could do such nasty things, the only thing on your board I can think of is a capacitor. Gets loaded when a 1 comes along; doesn't do any harm if the next signal is also 1, but gets short-circuited to ground when it sees a 0,probaly take the last 1 on the line with it.
You probaly looked at your board a thousand times, but could you do it once more? Follow the Data-line and watch out for any of the capacitors touching it by accident.


Eberhard

[Jon]

Ok we try sending

11111111 00000110 00000110 00000110 00000110

and the result as you predicted is

11111111 00000010 00000010 00000010 00000010

So it is time to call CSI downunder, and we start searching to see if any of those hungry capacitor animals are stealing my data. Cant find any trace of them touching the datalines or anything apart from the power and ground which they are allowed to feed from.
Feeling reckless, I decide to confirm 100% that its not the capacitors and I do what any crime investigator would do, and I remove them from the crime scene. With the caps on all IC's removed and placed 10 feet from the board, I try again.

No luck, still getting the same result.

Your theory number 2 sounds like it could be what is happening, but with the caps removed I cant see what else it could be, unless there is something in the 74595 doing it.

Jon

[Jon]

The serial data being sent to the 74595 is getting there correctly. I can switch the rows off and on as I like by setting serialdata(32=>40)
This leads me to believe the data loss is happening after the serial output from this to the MIC5821's
Gee, I wish I had a way of measuring the serial data as it travells in and out of each of the chips. Any one know of one?

[wayoda]

Gee, I wish I had a way of measuring the serial data as it travells in and out of each of the chips. Any one know of one?

Running the test-program you wrote in the debugger and put a breakpoint into the loop that shifts the data into your board.
(If you don't have a debugger, simply put a Console.readkey() into the loop that makes your programm wait for a key before it goes on)
If you stop at the breakpoint just before the Clock-Signal is generated, you should be able to measure the signal at the serial output of the 595 with a multimeter.

Eberhard

[Jon]

Thanks for that tip Wayoda, worked a well. Sometimes you just think that it has to be done the hard way!

Results of tonights test.

databits measured at the pins gave the following reults. They were measured just before the clock pulse.


************* --------Clock pulse --(1=>40)------------------------------ -- LED displays
Pin14 74HC595 01100000 01100000 01100000 01100000 11111111 - 11111111
Pin2. Mic821(1) 00000000 01100000 01100000 01100000 01100000 - 01000000
Pin2. Mic821(2) 00000000 00000000 01000000 01000000 01000000 - 01000000
Pin2. Mic821(3) 00000000 00000000 00000000 01000000 01000000 - 01000000
Pin2. Mic821(4) 00000000 00000000 00000000 00000000 01000000 - 01000000

next test....

************* --------Clock pulse --(1=>40)------------------------------ -- LED displays
Pin14 74HC595 01110000 01110000 01110000 01110000 11111111 - 11111111
Pin2. Mic821(1) 00000000 01110000 01110000 01110000 01110000 - 01100000
Pin2. Mic821(2) 00000000 00000000 01100000 01100000 01100000 - 01100000
Pin2. Mic821(3) 00000000 00000000 00000000 01100000 01100000 - 01100000
Pin2. Mic821(4) 00000000 00000000 00000000 00000000 01100000 - 01100000


So the interesting thing is, it goes into the 74HC595 and out OK.
It goes into the first MIC5821, but comes out missing a '1' . It must be dropping that '1' as it goes in because it is not staying in the input register for the strobe signal to move it into the output of the MIC5821.
I assume the other MIC's are OK as they are holding the '1's that are sent.

Time to sleep on these and see what my subconsience tells me :)

[Guido Körber]

This sounds like a race condition. The 595 maybe is faster in reacting to the clock than the MIC, so it already has changed the bit before the MIC does react on the clock.

I will have to check the timing data on Monday.

[Guido Körber]

OK, my fault, I should have written that into the app note...

The problem is that the MIC5821 requires a data hold time of 75nsec or more. But the 595 has a clock to QH propagation delay of only 20nsec or less.

So actually a capacitor on the data line between the 595 and the MIC would help. But the cleaner approach would be to put in a gate with a propagation dealy of 100nsec or so.

[Jon]

Thanks for finding that out, but I think I will scrap this method and try using a MIC5895/5891 for the row driver. Seems like there is going to be too much trial and error to get it to work.
Can you tell me, is the 5895 capable of powering all 32 segments of the row that may have to be on at once? I suppose if it isnt, I could always use the transistors as well.

[wayoda]

Since its time to update the Application Note anyway:

There is another small mistake in Figure 3 (Segmented Matrix) Page 7:

The 100nF capacitor at the second 5891 (third chip from the top) is connected to +5V and LedSupply. I guess it should be connected from +5V to ground just like the one at the first 5891 (top of the page).

Eberhard Fahle