Thank you Mike again for your wisdom!

It does appear that if you want to use the SXB "PWM" command that you have to connect the SX chip pin to an RC integrator network to create an analog voltage - from what I can read about the "PWM" command.

Now another possiblity is that I read on the Parallax forum that one of their other SX chips - the SX48 (I am currenly using the SX28 - less pins, memory, I/O, etc..), that the SX48 has PWM timer registers that the SX28 does not. Does this sound like something that can be used for PWM?

SX48 Timer for PWM forum Q&A:

Question:
Can someone help explain how the Clock speed say 50 mhz and Timer R1 and Timer R2 effect the PWM output. What is optimal for a PWM Frequency. What are some good settings.

Answer:
8 Bits = 256 clocks = 50MHz / 256 = 195.3125KHz PWM Frequency
10 Bits = 1024 clocks = 50MHz / 1024 = 48.828125KHz PWM Frequency

In SX/B you can simply use "TIMER1 PWM, value, 256" for 8 bit or "TIMER1 PWM, value, 1024" for 10 bit.

Sounds like a software overhaul as you stated though if the SXB "PWM" software command can not be used with the RC network - or the SX PWM timers for an SX48 can't be used correctly for this.

 

Nor will you, what you have is a message board controller!, not a full color or video controller with built in PWM. When using these type of controllers you don't PWM anything, you write a duty cycle value to an internal register of the controller chip. For the previously mentioned NXP chip, its I2C controlled, in Basic syntax:
I would get your money back if you were expecting those modules to do full color or video.

 

Look at the bottom of the page at this link.

You will see a Full Color LED Display controller for the PC that controls this card. I am trying to interface directly with these modules so that we can bypass or perhaps come up with a similar PC card that is controlled with a micro-controller like the Parallax SX28 or SX48.

This installation manual link should provide more detail about how these modules work. On page 17 of 26, it shows a "Receiving Card" that all of these modules plug into which then goes to the Full Color LED Display Controller - once in the PC.

So this proves that only the pins on the input and output jacks are used and it can perform full color (WHICH MUST MEAN IT CAN DO "PWM" OF SOME SORT to get 36 Bit color resolution).

I am working on this for a client as a test to see their capability with a micro-controller. I beleive PWM is possible after reading though all the SPECs and Data.

The only signals on each module are as follows:

R1A, R1B, R2A, R2B, G1, G2, B1, B2, CLK, LATCH, /OE, GND.

Somehow from these connections, PWM has to be possible.

Comments?

 

The basis for saying that it is a message board controller comes from the datasheets at this website, had to use Google translate. Pretty funny when they talk about the latch it comes out "bolt lock". Now the the datasheet they have is a MBI5024GF and so if that differs significantly from the "GP", I apologize. The other MBI controllers talk about PWM, full color, and video.

There is an Ebay auction using the MBI5026GD controller. That datasheet, is also classified as a message board controller. It looks to do full color/video.

Well it is a mystery. The Ebay board has a boatload more circuitry, which could handle the pwm. If the pwm is somehow done in software , then more power to them.

 

I have asked others on the Parallax forum about this display. There response is that they have used PWM via Interrupts or PWM Timers on the SX chips. They did say that since there is only (1) /OE line tied to all of the displays, that if can only get 256 shades of "ALL" of the RGB LEDs. This means it is only 8 bit but the datasheet says these types of FULL COLOR OUTDOOR display can work to 36 bit which is what I would expect for video input of "FULL COLOR". How can these PCBs with a set input signal jack get 36 bit color with only these signals: R1A, R2A, R1B, R2B, G1, G2, B1, B2, CLOCK, LATCH, /OE, GND.

Where does one get the experience or training to design to these set hardware designs. Just trying to understand so please don't be offended.

Comments?

 

please forgive my ignorance if im a mile off - and my lack of technical terms - but on the data sheet it says the clock can be pulse on/off in 20ns, therfore 20ns on,20 ns off = 40ns per pulse

40ns * 64 = 2560ns (2.56ms i think)
+ say 40ns for the latch = 2.6ms

at a refresh rate (for the single module) of 20Hz (should be ok for video), that is 40ms between refreshes

therefore you have 40/2.6 = 15 (and some change) chances to turn each led on or off per refresh

so by dividing the brightness of each pixel by 15, and sending an 'on' for that pixel for that many cycles you have 15 levels of brightness for that led.

sorry i cant explain better:- but if you want a pixel at half brightness, then from the start of the refresh you send a 'on' the first 8 times, then an 'off' the remaining 7 times.

that would give you a half brightness led

repeat that for all 4 pixels and you get (15^4) thats 15 brigness ^ 4 leds = 50625 colours (not as many as youd like) but a start

please dont flame me too much - im a newbie and i dont read chinese


EDIT:

just re-read the diagram, same principle but it clocks in 8 lines simultainously * 64 bits (on the driver board) , and does each colour led independently

but still do-able

 

SMUGangsta,

This is certainly a new approach not thought of and may be doable. However, I'm not following everything you say. Can you be a bit more specific or break it down for me more to understand a little more.

You also say that it clocks in 8 lines simultaneously. Remember that these boards can be cascaded to dozens or a hundred or more display boards so clock or a latch or an /OE affects ALL MBI5024GF LED driver chips and subsequently all of the cascaded display boards attached (not just 8 you see in the drawing).

There are 2 data streams on each 16x8 module (upper 4 rows and lower 4 rows with 16 columns for each pixel set of R, R2, G and B leds = 16 columns * 8 rows * 4 LED pixel sets = 512 LEDs per module). So 512 LEDs / 16 outputs per MBI5024GF LED driver = (32) MBI5024GF LED drivers per each 16x8 module. This means there the CLOCK, LATCH and /OE are going to (32) MBI5024GF LED drivers for each 16x8 module. Remember if they are cascaded (like I have 2 of them cascaded - but many many more could be for a huge display), the CLOCK, LATCH and /OE goes out to ALL OF THE MBI5024GF LED drivers not just 8 lines. So I don't understand what you meant by that. Please clarify.

Currently I am just toggling the clock signal at the speed of the SX28 micro-controller running with a 20 MHz resonator. However, I could use a 50 MHZ resonator if needed.

However, if the CLOCK should be on for 20 ns and off for 20 ns, it should be possible. I could do something like this in SXB for the SX28 chip:

CLOCK = 1
PAUSEUS 0.02 'a 20 ns pause
CLOCK = 0
PAUSEUS 0.02 'another 20 ns pause

SO your next calculation is a bit off I thinK.

40ns * 64 = 2560ns (2.56ms i think)
+ say 40ns for the latch = 2.6ms

I think it should be:

40 ns * 64 * 2 (upper and lower data streams = 128) = 5.12 uSec (-not mS-)
+ 40 nS for the latch = 5.12 uSec + 0.00004 uSec = 5.12004 uS (Right?)

You then state:

at a refresh rate (for the single module) of 20Hz (should be ok for video), that is 40ms between refreshes

Where did you get these numbers from?
Is 20Hz a calculation or stated on the data sheet somewheres?

I think you are on to something if we can work through these numbers.

Waiting for your reply!

Thanks so much.

 

20 Hz is based on the fact that 20Hz is an accptable rate for viewing video, although we are used to 25Hz on our tv. For an LED tv - 20Hz should be more than enough.

first off i thought it was a single 64 bit train that controlled it, then i realised that its not - each of the 8 inputs (R1A,R1B,G1,B1)bottom (R2A,R2B,G2,B2)top are are clocked at the same, so you are actually clocking in 64Bytes every latch.

oooooo - now thats a problem I messed up and your right, it does go from nano to micro to milli, in which case what are you waiting for??? because the 40ms between refreshes is right, so you would theoretically flash each led 15625 times between refreshes.

you could flash each and every led 256 times betweens refreshes - thus 4294967296 possible colours??

it was late when i did the maths, so my brain was melting, but i think the theory is good

that massive gap between micro and milli will let you udate a whole lot more displays and keep a high refresh rate

 

20Hz is probably a little on the low side, some people can see flickering on normal 50Hz TV's (25 frames per second) - dropping to 20Hz is going to mean a LOT more people will see the flickering.

__________________
PIC programmer software, and PIC Tutorials at:
http://www.winpicprog.co.uk

 

We have th big LED TVs in swansea town centre (BBC NEWS24), as well as they spinning video screens, and they flicker very visibly, but as a start having 20Hz would at least be a video, and if the time left between refreshes (after fetching data and processing it) is enough you can up the refresh rate, who knows - if you can process the incoming data fast enough you could mabey get 30Hz.

My appologies Nigel, I never realised that 50Hz was only 25 frames, where I have specifed 20HZ i was meaning 20 Frames per second. Out of curiosity why is this, do we have interlaced frames in the UK

 

As far as I'm aware all the world have interlaced TV?, the UK and Europe has 50 interlaced fields giving 25 frames, and the USA has 60 interlaced fields giving 30 frames. For HD there are essentially two formats, 1080i (interlaced fields) and 720P (progressive single field) - plus 1080P, used by BluRay, and not a broadcast format.

Just as with CRT sets, LCD's are now available as 100Hz, and the very latest Sony is 200Hz - but there's no flickering problems with LCD/Plasma anyway, as they aren't scanned.

__________________
PIC programmer software, and PIC Tutorials at:
http://www.winpicprog.co.uk

 

OK - Lets do this again.

tw(CLK) = 20 nS on time and 20 nS off time = 40 nS total CLOCK pulse time

40 nS total CLOCK * 64 bits (or 8 bytes) per RGB input (which is 8 RGB inputs to cover both upper and lower data streams) = 40 nS * 64 * 8 = 20.48 uS
Add to this total CLOCK time (20.48 uS) the 40 nS for the single Latch (20.48 uS + 40 nS) = 20.52 uS to clock through data for (1) 16x8 RGB LED module.

In the US, TV scanning is at 60 Hz so Time = 1/Freq = 1/60 Hz = 16.67 mS refresh rate.

16.67 mS refresh / 20.52 uS = 812 chances to turn on each LED on / off per refresh.

So by dividing the brightness of each pixel by 812, and sending an 'on' for that pixel for that many cycles you have 812 levels of brightness for each led.


I can't figure out the rest of your calculations to get the colors and other factors. Can you break down the calculations?

If I have more 16x8 modules cascaded, then all would be multipled out too.

Do I have this right?

 

Yeah you seem to have the jist of what I was trying to say (im very impressed because I dont understand it - lols)

My assumptions on colours is that the number of times you can turn on/off an led (brigtness) between each refresh defines how many differnt shades of led colour is possible (within reason - obviously on for 1ns isnt going to work) so if we say (as per your calculation that a refresh happens every 16.67ms, then you take that and divide it by a sensible number of shades (256 springs to mind) so the led 'on' or 'off' period would be 65uS, so for 50% brightness it would be on for 65uS * 127 (half of 256 available shades) = 8255uS out of the 16670uS available between refresh. << thats your (16.67mS)

we have 256 shades of say red = 256 ^ 1 = 256 Colours possible 256
and 256 shades of red2 = 256 ^ 1 = 256 Colours possible = 256 * 256
and 256 shades of green = 256 ^ 1 = 256 Colours possible = 256 * 256 * 256
and 256 shades of blue = 256 ^ ` = 256 Colours possible = 256 * 256 * 256 * 256

or 256 ^ 4 depending on your preffered way of writing it

256 ^ 4 = 4294967296 possible colours

That is unless both reds need to be on simultainiously, in which case it would just be 256 ^ 3 or 16777216 colours which is 24bit colour - more than enough for a tv (at least until you get it all working properly)


As i stated im not a technical person - just trying to be logical.

__________________
There will come a day when PICs will rule the world!

 

OK - To recap:

tw(CLK) = 20 nS on time and 20 nS off time = 40 nS total CLOCK pulse time

40 nS total CLOCK * 64 bits (or 8 bytes) per RGB input (which is 8 RGB inputs to cover both upper and lower data streams) = 40 nS * 64 * 8 = 20.48 uS
Add to this total CLOCK time (20.48 uS) the 40 nS for the single Latch (20.48 uS + 40 nS) = 20.52 uS to clock through data for (1) 16x8 RGB LED module.

In the US, TV scanning is at 60 Hz so Time = 1/Freq = 1/60 Hz = 16.67 mS refresh rate.

16.67 mS refresh / 20.52 uS = 812 chances to turn on each LED on / off per refresh.

So by dividing the brightness of each pixel by 812, and sending an 'on' for that pixel for that many cycles you have 812 levels of brightness for each LED.

A sensible number of shades is 256 so the LED on or off period would be:
16.67 mS / 256 shades = 65.104 uS.

For 50% brightness this would be 65uS * 127 (1/2 of the 256 shades) = 8.268 mS.

So this gives us 8.268 mS available from the 16.67 mS for 50% brightness.

We have 256 shades of say red = 256 ^ 1 = 256 Colors possible = 256
and 256 shades of red2 = 256 ^ 1 = 256 Colors possible = 256 * 256
and 256 shades of green = 256 ^ 1 = 256 Colors possible = 256 * 256 * 256
and 256 shades of blue = 256 ^ ` = 256 Colors possible = 256 * 256 * 256 * 256

or 256 ^ 4

So 256 ^ 4 = 4,294,967,296 possible colors = 32 bit color

That is unless both reds need to be on simultainiously, in which case it would just be 256 ^ 3 or 16,777,216 colors which is 24bit color - more than enough for a video based LED display.

-------

So now we know how it may be possible to get 32 bit color ON A SINGLE 16x8 RGB LED DISPLAY MODULE (even though it is possible somehow to get 36 bits - but I'm more than happy with 24 or 32 bit), How do I apply this?

I stated before to add in delays or pause statements of 20 nS for the Clock on and 20 nS for Clock off. And probably want to do this also for the Latch.

How can this be information be applied to the /OE to get the 256 shades per LED?

 

working on it now

__________________
There will come a day when PICs will rule the world!