Full brightness multiplexing.

Another point I have been ignoring, while trying to maintain maximum brightness, is that each time I buy another batch of LEDs they are much brighter than the previous ones anyway !

It was only a couple of years back that normal ( 25mA ) cheap LEDs broke through the 1000 mcd mark, now 11,000 are common.

DC42 suggested

Why not use thirteen TPIC6B95s as the column drivers and eight P-channel mosfets as the row drivers?

Sounds a good idea , and I have built a test panel, but only 7 x 5 LEDs. ( I only have enough LEDs for the project in this format ! I am going to leave a physical gap between each character display - later on I might move to 8x8 and do scrolling )

I want to get this one panel going to test in the sun.

I have 5 rows driven by mosfets, and 7 columns with 7 resistors to DRAIN1 to DRAIN7 of the TPIC6B595. ( DRAIN0 not used )

One problem is that I have migrated to the RFM22B wireless modules ( and RF22 library ) that uses SPI and the pin 2 interrupt.

I have been using Shiftout to run my 7 seg displays ( latching ), but I now have have 24 characters that I wish to update , and it sounds like SPI is the way to go speed wise to multiplex each row sequencially ? Crossroads uses SPI for everything ( sorry this is new ground for me )

I have used SPI and each driven chip needs a chip select input ? So if I need 24 chip selects I could do that with 3 CD4017s and one clock pin of the arduino ?

My old Shiftout version just pumps out the data to the first data in pin.

If the receiver detects an interrupt ( I am hoping it is only when a message arrives ) it will presumably disrupt the display refresh?

I could possibly blank the display with the notG while it is dealing with the incoming data..

I am also trying to get my head round the array to store the data in. It used to be a binary byte for the 7 seg , which I just called up for shifting out the data for each digit.

Now I must send out the right byte pattern for the top row of the number for each digit, latch it in, then load the second row, and so on ?

I have searched for a library to do this, but they seem to be devoted to particular chips ( which are expensive here )

I am going to write a sketch to run this one display to show a couple of letters, using shiftout for now, if anyone has some pointers I will appreciate it .

Boffin1:
I have used SPI and each driven chip needs a chip select input ? So if I need 24 chip selects I could do that with 3 CD4017s and one clock pin of the arduino ?

You don't need 24 chip selects, you can daisy=chain the TPICs from the SPI pins just like you do with ShiftOut. So one CS pin for all the TPICs.

Boffin1:
If the receiver detects an interrupt ( I am hoping it is only when a message arrives ) it will presumably disrupt the display refresh?

If the ISR uses SPI to communicate with the radio, then possibly, but not necessarily. It depends on how the ISR is written, and on whether you can use the same SPI clock fate for both devices. Or, if you can afford to wait a few microseconds before servicing the interrupt (which depends on whether the receiver can buffer incoming data), then you can disable interrupts while you send data to the TPICs.

Boffin1:
I am also trying to get my head round the array to store the data in. It used to be a binary byte for the 7 seg , which I just called up for shifting out the data for each digit.

Now I must send out the right byte pattern for the top row of the number for each digit, latch it in, then load the second row, and so on ?

Use an array with 8 bytes per 8x8 display, one byte for each row. Shift out the bytes for the rows you want to update.

Boffin1:
I am going to write a sketch to run this one display to show a couple of letters, using shiftout for now, if anyone has some pointers I will appreciate it .

The standard ShiftOut is extremely slow. It is not difficult to write a much faster version. See the code starting at line 446 of arduino/lcd7920.cpp at master · dc42/arduino · GitHub. It could be made even faster by calculating and storing the port address and but mask just once during initialization instead of once per byte sent.

Thanks thats pretty encouraging.

You don't need 24 chip selects, you can daisy=chain the TPICs from the SPI pins just like you do with ShiftOut. So one CS pin for all the TPICs.

OK so I will use MOSI for the data, clock for clock, and CS for latch .

The RF22 presumably sets the polarity, speed, etc for the SPI, so I will just fit in with that with a different CS pin?

Or, if you can afford to wait a few microseconds before servicing the interrupt (which depends on whether the receiver can buffer incoming data), then you can disable interrupts while you send data to the TPICs.

I usually send the transmission several times anyway to be sure ( its just updates of scores now and again ) so I can disable interupts while refreshing each rows data. ( if the SPI is fast enough there should be time before the next refresh using GMikes timing check )

I also have a countdown clock that I use "blink without delay" routine for, using millis(), will this be OK ?

Use an array with 8 bytes per 8x8 display, one byte for each row. Shift out the bytes for the rows you want to update.

Thats basically what I am putting together now for the test which I was going to try with shiftout, but I will try SPI instead.
Can I send out 24 bytes in one go while the CS is low, and then raise it to latch the data?

I'm afraid the example with the LCD display is confusing for me at the moment, I will try my baby steps method to get it running with one panel, and see what happens with 35 LEDs up against the African sun in the morning.

Boffin1:
Can I send out 24 bytes in one go while the CS is low, and then raise it to latch the data?

Yes, you can.

Great, thanks , long night ahead ...

Boffin1:
I think I will have to knock up 2 samples of my 7x5 display and actually test it in the sun while varying the duty cycle of the one.

Crazy.

Well, crazy or not Hippynerd, I did the test, ( as you suggested in the second post of this thread ? ) and the difference is like chalk and cheese.

As I said, there are so many contradictory theories out there when I Googled about multiplex / brightness /pwm, that I had to check for myself.

Have a look at the photos, they are as they appear to the eye, the second 12% multiplexed row of LEDs are supposed to be only half the perceived brightness of the middle 100% row.

I do not have the time to measure the results unfortunately, but while I might get away with the 100% row at 50 meters into the sun, with a bit of filtering , there is no way the 12% row will work. ( I don't have the budget to use the power LEDs that the big video screens use )

I have no idea how much extra current at 12% would be needed to bring the " brightness " up to the level of the 100% LEDs, but the manufacturer of my LEDs does not recommend pulsing them at more than 25mA anyway !

Sorry to say, multiplexing will not work for my project, it would have saved me 80% of the cost of driver chips , ( which I had budgeted for anyway ) but I would have had to go for a double sided pcb and some Mosfets.
And then there might have been problems running the high speed SPI data to each of the 24 displays over 2 meters.
With Shiftout the fastest response I need is to change the timer display every second , and I dont have to worry about the receivers interrupt.

I see a lot of videos people put on you-tube of their LED multiplex projects, but many record them with the room lights off.
Take the board outdoors on a clear day, with the LEDs facing into the sun, and let me see the results, this is the worst case scenario I have to cater for with my outdoor projects.

Thanks everyone for your inputs, it was worth a try, and very interesting.

That is a good experiment. Im unclear about the 12% number. If you are running one row at a time thats 1:7, or about 14%, if you run them 1:5 you should be at 20%.
My guess is 20% will end up being only about 1/2 as bright as full on.

I wonder if results would be different, if they were done indoors?

I will probably have to do some testing too, Im curious about how brightness will vary depending on duty cycle.

The best way to take pictures of LEDs seem to be in dim light, with the camera set for outdoor (natural light).

Yes, I got that confused with the 8 outputs of the TPIC, it should read 20%, I am switching 5 mosfets to feed the rows, and 7 outputs of the TPIC are sinking the respective LED columns.

The difference does show up indoors, but I had to take the shots from far away and crop the target, or the camera changes its exposure for the different levels. At a distance it measures the average room light.

The brightness at 20% would be fine indoors, it is still very bright to look straight into, but for example in my lit room, when the 100% row is lit, there is a big blurred red light on the ceiling, but when the 20% one is on you can hardly see it on the ceiling.

I took the earlier pics at sundown in the only spot of sun available. I will try it in the morning in the full sun, and try walking down the road, and take some more pics, but I am not too hopeful.

I will definately use multiplexing for my indoor projects, but as I said, the normal LEDs get stronger every few months, so it will reach a point where the 20% is bright enough - soon I hope !

I would like to use multiplexing with some tail lights, and my guess is that brightness will be an issue. I have no idea how im ever going to get around to it, but its still in the head scratching phase.

I think there are really too many factors to calculate things, the electronics stuff can be measured and calculated, but perception and biology are weird enough that I think you really have to test stuff to see how well it will actually work.

Tail lights that you can play pong or tetris on are just too fun to not try.

I see some cars have pwm for the brake / tail lights, my wife thought I had lost it when I kept shaking my eyes / head at cars in front ( to see if the tail lights were PWM brake lights - the line of dots )

I dont know how they measure the perceived brightness, ( I have never studied light ) the difference in brightness of my two rows doesn't look too bad when you look at the LEDs directly.
Why the dimmer one fails to even show on the ceiling, or can hardly be seen in sunlight, doesn't seem to tie in.

The LEDs I am using are only 3,000 mcd , I have asked my supplier to quote on their 18,000 mcd version, presumable PWM at 20% would give me more light than my current one on 25 mA DC.

But I am not too sure anymore :slight_smile:

I just had a thought. Do your signs have to be red LEDs? It seems to me the red are the lowest of the brightness, with a tail light, you need red, white ones with a red lens wont produce as much light as a red LED (another thing to test...), so for tail lights, you need red, but for sign board, you might be able to use a color that produces more light (white? blue?).

I have some RGB LEDs in front of me, and it says the red are 2000-2500 mcd, the blue are 2500-3000, and the green are 6000-7000 MCD. maybe you should be using green LEDs?

Its true that the green are VERY bright, ( OK they run at a higher power than the red - the voltage being higher for the same 25 mA )
My supplier offered me 20 odd candela cheaper than the weaker red ones, but for some reason people want red !

OK I can't use blue on outdoor displays or the emergency services would complain, but both green and blue are much brighter.

The white ones 30 degrees are now 26,000 mcd.

The other consideration is that I need 1680 LEDs for this project, and I still have 1720 in stock !

The final outcome of my experiments for an outdoor text display work fine, I am using SAA1064 chips multiplexing at 50%,

I left the board facing the sun for 3 hours, and the front was too hot to touch ( the customer wanted black ! ) but I fitted a fan inside and the air coming out the ventilation vents was less than 40C.

My LED supplier can now sell me LEDs 5 times brighter than these, so I will go normal for multiplexing for the subsequent boards !

The human eye is more sensitive to green light, so green LED usually appear brighter than the red, or the blue.
This article may also of interest if brightness perception is an issue:

https://ledshield.wordpress.com/2012/11/13/led-brightness-to-your-eye-gamma-correction-no/

There is a big error with that board.
During the whole of the first half Man United have not scored!!!

By the way, did you know I used to teach Garry Bailey, I supervised his final year project as well.

@ headroom, thats another interesting article. As it says there are misconceptions and I just used my simple tests - trying different M/S ratios on the actual batch of LEDs I was going to use, and taking them out in the sun to see at what point they became difficult to discern.

Even 25% was not good enough, but It might be that I have chosen the 50% ratio to suit my strange eyesight !

Yes the green is definately brighter, which always made me wonder why we chose red as a danger signal, or traffic light. Perhaps it was the easiest colour to generate using a fire with a filter ?

@ Mike One of the bugs I have to sort out today is that after I had boxed this one up for a photoshoot, I saw that if I change the scores, some of the LED columns go out ! But being both a ManU supporter, and an Edgemead resident, perhaps this was more PC.

Gary Bailey does a lot of TV commentary on soccer games here, what a great guy ( must be your influence Mike ) Wonderful sense of humour, and not Grumpy at all.

Gary Bailey does a lot of TV commentary on soccer games here,

Yes that is why I mentioned it. The last time I saw him I was driving through Manchester and we pulled up at the same set of traffic lights. He wound down his window and said Hi Mike, I said isn't it supposed to be the other way round? I also know Les Kershaw the chief scout, he used to lecturer in chemistry at my University. Mind you in Alex Ferguson's autobiography he called him a Physics lecturer. My grandad first took me to old Trafford when I was nine. It was so long ago Bobby Charlton had hair!
When I was in New York two years ago I was sold a "New York Reds" badge in the United Bar, they had a banner saying "New York Reds, like Urmston only bigger"