Zoot, Thank you again for hangin in there with me.
After looking closely at the basic program (attached) at 128 KHz, it did NOT remove the ghosting but because it had a slower refresh scanning rate, the offset ghosting was actually not faintly ghosted·but in full brightness along with the regular text message. So the ghosting never really went away when reducing the speed from 4 MHz to 128 KHz.
The attached program will scroll across·4 letters " " and " " and "P" and "h" but I can't show more than that because of the 255 byte FOR NEXT loop.
Something here doesn't make sense. Your data for, say, the letter "P" is
Ltr_P:
DATA 1,1,1,1,1,1,1,1
DATA 1,1,1,1,1,1,1,1
DATA 0,0,0,1,1,0,1,1
DATA 0,0,0,1,1,0,1,1
DATA 0,0,0,1,1,0,1,1
DATA 0,0,0,1,1,1,1,1
DATA 0,0,0,0,1,1,1,0
DATA 0,0,0,0,0,0,0,0
And you read by columns. The backpack LED driver wants pixel in top left corner first, then across by rows, so reading the above as you do I would not expect to see this character represented properly.
Looking at the display right side up, this is the order it would want bytes:
The way I read your code, and looking at data as you have it written, I would get the bytes in this order:
P:
DATA 0,1,2,3,4,5,6,7
DATA 8,9,10,11,12,13,14,15 ....etc
DATA 0,0,0,1,1,0,1,1
DATA 0,0,0,1,1,0,1,1
DATA 0,0,0,1,1,0,1,1
DATA 0,0,0,1,1,1,1,1
DATA 0,0,0,0,1,1,1,0
DATA 56,57,58,59,60,61,62,63
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
Although this looks correct within the DATA statements, I needed to turn the display on it's side to look like the letter P (otherwise it was lying on it's back - the letter P that is). However, when it scrolled with the current software (which probably needs to be changed)·it scrolls from the bottom to the top (unlike the original Ltr_P - which scrolled from the right to the left).
I have attached the program with the modification of the Ltr_P.
Keep in mind that I still saw the ghosted imaging of the letter P directly above the regular scrolling upward letter P.
Post Edited (T&E Engineer) : 10/29/2007 6:56:54 PM GMT
Although this looks correct within the DATA statements
-- I suggested turning it not so that it "looks" right, which is a nice coincidence, but so that the order of the data matches the order needed to go to the display.
, I needed to turn the display on it's side to look like the letter P (otherwise it was lying on it's back - the letter P that is).
-- the "top" of the display would be with the connector at top left (according to the datasheet, anyway). And remember to cascade with the "last" display "first" in the cascade order.
However, when it scrolled with the current software (which probably needs to be changed) it scrolls from the bottom to the top (unlike the original Ltr_P - which scrolled from the right to the left).
-- which would be expected since your scrolling routine grabs 8 bytes at time in order. Your current scrolling wouldn't work in this order. I didn't edit code, I was just pointing out that your data didn't match desired order of the display. Again, you might want to tackle this in reverse order -- instead of working on debugging scrolling, make sure you've got an ASCII bitmap set in BITS, then make sure you can correctly dump a character to the display without errors, THEN add scrolling into the mix. With 64 bytes per character you will not have much space at all for messages.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
I had a couple of home emergencies Monday·so haven't been too active on this project.
1. Hit a deer so my Ford Explorer is messed up in the shop - thank God for insurance / rental car, etc.
2. My 50" Sony TV stopped working - Cycles power off and on every 30 seconds. Weird.
However, here is my latest correspondance with SparkFun Support:
Chris,
I tried a CD4050BC Non Inverting Hex Buffer and I still saw the ghosting. I placed the 3 buffers between the Micro-controller CLK and the SCLK on the Single display matrix (where the statement ... DO WHILE tmpB3 < 129), buffer #2 between the microcontroller Data In and the DI on the Single display matrix, buffer #3 between the microcontroller ChipSel and the CS on the Single display matrix. I then connected the first matrix SCLK to the 2nd matrix SCLK, the first matrix DO to the 2nd matrix DI, and finally the first matrix CS to the 2nd matrix CS - and still saw the ghosting effect - just shifted over the 2nd display matrix.
I then tried a 74LS04 hex inverting buffer and tied 2 of them together to get a buffer (for 3 buffers total) and saw the ghosting effect.
I have attached a spreadsheet of my available ICs and components if you would like me to try something different.
One thing to mention is that the microcontroller is running at 4MHZ internal clock. However I was told·the SHIFTOUT statement is less than 83KHZ.
the ghosting·"appears" to go·away BUT the refresh scanning is· slow·and page rippling like (perhaps this is because it is in a BASIC like language). This is not usable to me like this.
Thanks Chris. This certainly makes it more clear. I am using a Parallax SX-28 microcontroller using a BASIC like language. I don't see this ghosting issue occurring with 64 bytes (1 display matrix - DataIn1, Clk1, CS1) - just anything more (e.g. 128+ bytes as seen on 1 display or 2 cascaded display matrixes (e.g. DataIn1, DataOut1 -> DataIn2, Clk1->Clk2, CS1->CS2).
So it sounds like I just need to buffer these 4 lines (for 2 cascaded displays). A set of buffers are need for each display matrix. Correct?
I have attached my test program. As you can see changing the 1 line from 65 to 129 causes the problem.
DO WHILE tmpB3 < 129
'65 will work with no ghosting. 129 causes ghosting on 1 or more displays.
Mr. Gilmore,
Sorry if that was a bit vague. The way I have it set up, the DATA IN,
CS, and CLK from the controller (I'm using a n LPC2106 from Olimex) are
sent to a buffer, which sends the signal to the LED matrix just via the
matrix's header. Then the DATA OUT from that matrix is sent to the next
buffer, and then from the buffer to the next matrix's DATA IN line. This
goes on through the whole array, and then the DATA OUT from the last
matrix is sent all the way back to the controller. So in essence, there
is a buffer in between each matrix, not on the matrix board itself. I am
buffering CS and CLK all the way down the array, so that each matrix
sees the same signal. A standard buffer or P-FET should work, as long as
they are fast enough for your application. I also have 100uF caps on the
power line near each matrix, just to be sure that I don't run into noise
issues.
-Chris
Gilmore, Timothy wrote:
> Chris,
>
> Thanks for the analysis work. When you say the data lines, can you be
> more specific? As this backpack device is serial it only has 3 or 4
> "accessible" lines being CLOCK, DATA IN, (DATA OUT) and CHIP SELECT.
>
> Or are you referring to the DATA lines between each of the 74LS595's and
> the RGB LED's on the backpack itself? This may not be that feasible and
> sort of defeats the purpose of the "plug in" backpack to the LED module.
> I tend to use ULN2803's for buffers (or P channel MOSFETs) on other
> projects. Is this what you are implying?
>
> Tim
>
>
>
>
>
>
Original Message
> From: Chris Taylor [noparse]/noparse][url=mailto:chris@sparkfun.com][u][color=#0066cc]mailto:chris@sparkfun.com[/color][/u][/url
> Sent: Tuesday, October 30, 2007 12:14 PM
> To: TIMOTHY.D.GILMORE@saic.com; spark@sparkfun.com
> Subject: Re: [noparse][[/noparse]Fwd: [noparse][[/noparse]Fwd: [noparse][[/noparse]Fwd: Re: Return 2 Large RGB LED Matrix and
> controllers & minor associated components]]]
>
> Hi Mr. Glimore,
> I am actually working on a very similar project. The ghosting you're
> seeing is due to signal integrity issues with the data lines. Sounds
> like your power supply is adequate. I have an array of 8 LED boards
> scrolling messages and patterns. I solved the signal integrity problem
> by buffering the data lines each step of the way with simple drivers. I
> used a 7HCT365 for the buffer, and it worked well for me.
>
> -Chris
Just came back from a few days R&R in the Great Smokey Mountains with the family.
I wanted to give an update on this project. Unfortunately I did not get much further with SparkFun technical support - which were helpfull. I was able to get an RMA # for a return. It's is a real shame because this would have been a neat project - even though very expensive at $60 each module. Displays with hardware controllers have been very difficult for me to find but hopefully I will find more in the future.
Thanks again Zoot and others for your great support on this project.
Comments
After looking closely at the basic program (attached) at 128 KHz, it did NOT remove the ghosting but because it had a slower refresh scanning rate, the offset ghosting was actually not faintly ghosted·but in full brightness along with the regular text message. So the ghosting never really went away when reducing the speed from 4 MHz to 128 KHz.
The attached program will scroll across·4 letters " " and " " and "P" and "h" but I can't show more than that because of the 255 byte FOR NEXT loop.
Let me know what else you need me to do.
Thanks!
And you read by columns. The backpack LED driver wants pixel in top left corner first, then across by rows, so reading the above as you do I would not expect to see this character represented properly.
Looking at the display right side up, this is the order it would want bytes:
The way I read your code, and looking at data as you have it written, I would get the bytes in this order:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
I changed the original Ltr_P:
Ltr_P:
· DATA·· 1,1,1,1,1,1,1,1
· DATA·· 1,1,1,1,1,1,1,1
· DATA·· 0,0,0,1,1,0,1,1
· DATA·· 0,0,0,1,1,0,1,1
· DATA·· 0,0,0,1,1,0,1,1
· DATA·· 0,0,0,1,1,1,1,1
· DATA·· 0,0,0,0,1,1,1,0
· DATA·· 0,0,0,0,0,0,0,0
to this:
Ltr_P:
· DATA·· 1,1,1,1,1,1,0,0
· DATA·· 1,1,1,1,1,1,1,0
· DATA·· 1,1,0,0,0,1,1,0
· DATA·· 1,1,1,1,1,1,1,0
· DATA·· 1,1,1,1,1,1,0,0
· DATA·· 1,1,0,0,0,0,0,0
· DATA·· 1,1,0,0,0,0,0,0
· DATA·· 1,1,0,0,0,0,0,0
Although this looks correct within the DATA statements, I needed to turn the display on it's side to look like the letter P (otherwise it was lying on it's back - the letter P that is). However, when it scrolled with the current software (which probably needs to be changed)·it scrolls from the bottom to the top (unlike the original Ltr_P - which scrolled from the right to the left).
I have attached the program with the modification of the Ltr_P.
Keep in mind that I still saw the ghosted imaging of the letter P directly above the regular scrolling upward letter P.
Post Edited (T&E Engineer) : 10/29/2007 6:56:54 PM GMT
-- I suggested turning it not so that it "looks" right, which is a nice coincidence, but so that the order of the data matches the order needed to go to the display.
, I needed to turn the display on it's side to look like the letter P (otherwise it was lying on it's back - the letter P that is).
-- the "top" of the display would be with the connector at top left (according to the datasheet, anyway). And remember to cascade with the "last" display "first" in the cascade order.
However, when it scrolled with the current software (which probably needs to be changed) it scrolls from the bottom to the top (unlike the original Ltr_P - which scrolled from the right to the left).
-- which would be expected since your scrolling routine grabs 8 bytes at time in order. Your current scrolling wouldn't work in this order. I didn't edit code, I was just pointing out that your data didn't match desired order of the display. Again, you might want to tackle this in reverse order -- instead of working on debugging scrolling, make sure you've got an ASCII bitmap set in BITS, then make sure you can correctly dump a character to the display without errors, THEN add scrolling into the mix. With 64 bytes per character you will not have much space at all for messages.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
I had a couple of home emergencies Monday·so haven't been too active on this project.
1. Hit a deer so my Ford Explorer is messed up in the shop - thank God for insurance / rental car, etc.
2. My 50" Sony TV stopped working - Cycles power off and on every 30 seconds. Weird.
However, here is my latest correspondance with SparkFun Support:
Chris,
I tried a CD4050BC Non Inverting Hex Buffer and I still saw the ghosting. I placed the 3 buffers between the Micro-controller CLK and the SCLK on the Single display matrix (where the statement ... DO WHILE tmpB3 < 129), buffer #2 between the microcontroller Data In and the DI on the Single display matrix, buffer #3 between the microcontroller ChipSel and the CS on the Single display matrix. I then connected the first matrix SCLK to the 2nd matrix SCLK, the first matrix DO to the 2nd matrix DI, and finally the first matrix CS to the 2nd matrix CS - and still saw the ghosting effect - just shifted over the 2nd display matrix.
I then tried a 74LS04 hex inverting buffer and tied 2 of them together to get a buffer (for 3 buffers total) and saw the ghosting effect.
I have attached a spreadsheet of my available ICs and components if you would like me to try something different.
One thing to mention is that the microcontroller is running at 4MHZ internal clock. However I was told·the SHIFTOUT statement is less than 83KHZ.
DEVICE········· SX28, OSC4MHZ, TURBO, STACKX, OPTIONX
FREQ············· 4_000_000
However·if I change this to:
DEVICE········· SX28, OSC128KHZ, TURBO, STACKX, OPTIONX
FREQ············ 128_000
the ghosting·"appears" to go·away BUT the refresh scanning is· slow·and page rippling like (perhaps this is because it is in a BASIC like language). This is not usable to me like this.
Comments?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
From: Gilmore, Timothy
Sent: Tue 10/30/2007 1:01 PM
To: Chris Taylor
Subject: RE: [noparse]/noparse]Fwd: [noparse][[/noparse]Fwd: [noparse][[/noparse]Fwd: Re: Return 2 Large RGB LED Matrix and controllers & minor associated components]
Thanks Chris. This certainly makes it more clear. I am using a Parallax SX-28 microcontroller using a BASIC like language. I don't see this ghosting issue occurring with 64 bytes (1 display matrix - DataIn1, Clk1, CS1) - just anything more (e.g. 128+ bytes as seen on 1 display or 2 cascaded display matrixes (e.g. DataIn1, DataOut1 -> DataIn2, Clk1->Clk2, CS1->CS2).
So it sounds like I just need to buffer these 4 lines (for 2 cascaded displays). A set of buffers are need for each display matrix. Correct?
I have attached my test program. As you can see changing the 1 line from 65 to 129 causes the problem.
DO WHILE tmpB3 < 129
'65 will work with no ghosting. 129 causes ghosting on 1 or more displays.
Tim
Original Message
From: Chris Taylor [noparse]/noparse][url=mailto:chris@sparkfun.com][u][color=#0066cc]mailto:chris@sparkfun.com[/color][/u][/url
Sent: Tuesday, October 30, 2007 12:42 PM
To: Gilmore, Timothy
Subject: Re: [noparse]/noparse]Fwd: [noparse][[/noparse]Fwd: [noparse][[/noparse]Fwd: Re: Return 2 Large RGB LED Matrix and controllers & minor associated components]
Mr. Gilmore,
Sorry if that was a bit vague. The way I have it set up, the DATA IN,
CS, and CLK from the controller (I'm using a n LPC2106 from Olimex) are
sent to a buffer, which sends the signal to the LED matrix just via the
matrix's header. Then the DATA OUT from that matrix is sent to the next
buffer, and then from the buffer to the next matrix's DATA IN line. This
goes on through the whole array, and then the DATA OUT from the last
matrix is sent all the way back to the controller. So in essence, there
is a buffer in between each matrix, not on the matrix board itself. I am
buffering CS and CLK all the way down the array, so that each matrix
sees the same signal. A standard buffer or P-FET should work, as long as
they are fast enough for your application. I also have 100uF caps on the
power line near each matrix, just to be sure that I don't run into noise
issues.
-Chris
Gilmore, Timothy wrote:
> Chris,
>
> Thanks for the analysis work. When you say the data lines, can you be
> more specific? As this backpack device is serial it only has 3 or 4
> "accessible" lines being CLOCK, DATA IN, (DATA OUT) and CHIP SELECT.
>
> Or are you referring to the DATA lines between each of the 74LS595's and
> the RGB LED's on the backpack itself? This may not be that feasible and
> sort of defeats the purpose of the "plug in" backpack to the LED module.
> I tend to use ULN2803's for buffers (or P channel MOSFETs) on other
> projects. Is this what you are implying?
>
> Tim
>
>
>
>
>
>
Original Message
> From: Chris Taylor [noparse]/noparse][url=mailto:chris@sparkfun.com][u][color=#0066cc]mailto:chris@sparkfun.com[/color][/u][/url
> Sent: Tuesday, October 30, 2007 12:14 PM
> To: TIMOTHY.D.GILMORE@saic.com; spark@sparkfun.com
> Subject: Re: [noparse][[/noparse]Fwd: [noparse][[/noparse]Fwd: [noparse][[/noparse]Fwd: Re: Return 2 Large RGB LED Matrix and
> controllers & minor associated components]]]
>
> Hi Mr. Glimore,
> I am actually working on a very similar project. The ghosting you're
> seeing is due to signal integrity issues with the data lines. Sounds
> like your power supply is adequate. I have an array of 8 LED boards
> scrolling messages and patterns. I solved the signal integrity problem
> by buffering the data lines each step of the way with simple drivers. I
> used a 7HCT365 for the buffer, and it worked well for me.
>
> -Chris
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
I wanted to give an update on this project. Unfortunately I did not get much further with SparkFun technical support - which were helpfull. I was able to get an RMA # for a return. It's is a real shame because this would have been a neat project - even though very expensive at $60 each module. Displays with hardware controllers have been very difficult for me to find but hopefully I will find more in the future.
Thanks again Zoot and others for your great support on this project.