Hardware for score board

M

mst

Member
Hi fokes,

I am converting a score board to run from picaxe and need some assistance with hardware choice.

The scoreboard is made up of 12* 7 segment displays.
Each 7 segment display is made from globes driven by a MOC3041 Opto Isolated Triac (1 triac per segment).
The triac requires 13.8v +ve @ 20ma constant current to drive (15ma switching threshold).
All 12 segments have a single common ground.

At the moment I am considering using 13* 18 pin pics. 1 master pic outputting serial data and 12 slaves receiving the stream and picking off the required value (0 through 9) and turning on or off 7 of it's 8 outputs to drive a segment.

Problem is what transistor to use to get the required 13.8v +ve @ 20ma?

Any help would be great :)
 
B

BeanieBots

Moderator
A datasheet for the triac would be very useful.

As these are optically isolated I assume what you need to drive is actually the LED of the isolator.
If this is the case, then it should be possible to drive it with just about any transistor via a suitable resistor from the PICAXE 5v supply.

Probably possible direct from PICAXE output (via resistor). Datasheet would confirm.
 
Last edited:
I

inglewoodpete

Senior Member
mst said:
At the moment I am considering using 13* 18 pin pics.
Click to expand...
I think 13 PICs or PICAXEs would be an over kill here, although RevEd and/or MicroChip would love you:)

Just use 1 PICAXE and a few shift registers like the 74HC595. Alternatively, look at the larger i2c output expanders.
 
M

mst

Member
I need 84 outputs in total. is it possible with the i2c expander? (I know nothing of this device)
 
W

westaust55

Moderator
I concur with InglewoodPete.

Have a look at this thread where I use three 74HC595’s to drive three 7-segment displays.
http://www.picaxeforum.co.uk/showthread.php?t=13687

All you need to do is expand the number of 595’s in cascade, which uses no more PICAE IO pins, and you are up and running.


Alternatively with i2c IO Expanders, yes use the MCP23017. Each has two 8-bit ports so 16 IO per chip.
84 outputs would need 6 chips. You can have a maximum of 8 such IO expanders on a single i2c bus.
Do a search on this forum. I used two MCP23017’s in a multiplexing arrangement to drive a total of 192 LED’s as an 8x8 RGB LED matrix. Bit of flicker with the multiplexing but if each LED is driven directly no such problems would exist.
 
B

BeanieBots

Moderator
Also, if you use an IO expander, careful choice would eliminate the need for any transistor drive of the opto. Simply drive it like an ordinary LED via a resistor. Just be careful of the maximum package current as well as individual output limits.
 
A

azar

New Member
If you wish to furthur minimise your chip count, you could use either the
A6812, 20 bit serial latch and cascade them or the A6820, 32 bit equivelant.
 
A

Andrew Cowan

Senior Member
You could also use shift registers with latches - such as the 74HC595. Alternativly you could use 4511s - these BCD to 7 segment chips have a latch built in.

A
 
N

nbw

Senior Member
The DIP version of the MAX7300 IO expander will give you 20 ports, from memory. If you go SMD, you might get 28.
 
M

mst

Member
I looked at the options and I think I may go with my original idea in this case (as long as no one hates me!).
Wiring up is going to be much easier if I go with a 18x behind every 7 seg module and send data to them. (the segments are around 1.5 meters tall). So all I'll need to bring is a twin and shield to each unit (data, 12v and ground).
I'll regulate to 5v locally.

I don't realy have a good grasp on sending and receiving serial data.
I have the numbers stored in 6 vairables and need to send it to the other picaxe's, I guess in a string of 12 numbers and have each pic 'pick off' the number it needs and store that in a vairable.

Any ideas? / can you explain it so I don't need to ask again :D
 
M

MartinM57

Moderator
SERTXD and SERRXD are your friends - see Manual 2. But not on an 18X :(, so you may have to reconsider that choice.

SERTXD a string from the master that is all twelve numbers concatenated and get each slave to SERRXD the whole string and pick off the number it wants (need to program each slave with its 'number' - hardwired, DIP switches or individually programmed in the software - pros and cons for each)

Need to watch out for the SERRXD behaviour - no timeout on some PICAXEs (see manual), so your slave code will hang at that statement until data received. May or may not be an issue. If it is an issue you will need an X part.

With your solution you will be doing "fire-and-forget' from the master. If the slaves aren't listening, are doing something else, have fallen off the bus etc, you will never know.

You need to decide whether to only transmit when any digit changes or periodically - say every 0.5 seconds. Pros and cons etc

With serial comms you are strongly advised to use a PICAXE that uses an external resonator (see SETFREQ) so that you are guaranteed accurate baud rates for the master to transmit at and the slaves to receive at.

Nice project - if each segment is 1.5m tall, it's one helluva scoreboard :) What's it for?
 
W

Wrenow

Senior Member
mst said:
.

I don't realy have a good grasp on sending and receiving serial data.
I have the numbers stored in 6 vairables and need to send it to the other picaxe's, I guess in a string of 12 numbers and have each pic 'pick off' the number it needs and store that in a vairable.

Any ideas? / can you explain it so I don't need to ask again :D
Click to expand...
All things considered, you might want to relook at the 74HC595 instead as suggested by more than one. You use one for each seven segment display and only need to run 3 signal lines to each sequentially (they daisey chain nicely). I believe it will simplify things and keep your costs inline while largely maintaining your concept.

Basically, the Picaxe sends the data out over the lines, and each 595 controls its display. No need to program the 595's, as they are dedicated to their job of taking the data received and turnng the segments on and off.

Cheers,

Wreno
 
M

mst

Member
It's for a speedway, they have the scoreboard however the controller they are using is a contraption that has like 2 stopwatches in it and 30 various knobs and buttons. It's a nightmare to run and is so old it looks as if it should have a boiler!
So the scoreboard is fine, just needs better control.

This is a short term solution which will provide the same as the last unit except 300% easier to use. Following this I am going to attempt to use the timing computer's datronics output (serial formatted for use on a datronics display) and display selected data on the current scoreboard.

It goes somthing like this:
88.88.88
minutes.seconds.tenths/hundredths

The remaining 4 digits are for lap number (count down 2 digits) and race number (count up 2 digits). I have reserved 2 digits for future use.

I would like the output to be able to keep up with the tenths, does anyone know how to calculate what clock speed/data rate might be required to do that? Obviously an entire cycle of events would have to occur in around 9 hundredths of a second (to leave time to spare for the picaxe to be ready for the next data stream).
 
hippy

hippy

Ex-Staff (retired)
No reason not to use a PICAXE per display digit IMO, the PICAXE part will likely be a small part of the total cost and you can gain some of that cost back anyway with ease of use.

You can have a system which sends a digit indicator and a digit value and have up to 16 digits displaying 0-9 plus some other characters like "-" and blank by sending a single serial byte. If you want hundredths of a second you've got to update say 10 digits in 10ms so that's 1ms per digit. I'd go for 20X2 running fast and using HSERIN. I cannot say it will work but I would have thought it could, and there are other tricks which will allow slower update speeds but keep to 100th's of a second - Not that anyone will be able to distinguish 100th's anyway - so the hundredths digit may only need sending at the end of timing.

With the digits display out the way ( and that's fairly simple code in each PICAXE ) all you need is another PICAXE or PC or 'something' which sends the data required in the expected format and at the right speed.
 
M

MartinM57

Moderator
Ah...so a(nother) key requirement now comes to light - it's for a clock that has to show tenths/hundredths of a second :D

I formed the impression that the segments are mechanical - can they keep up with the tenths? Presumably (I presume, as you're telling us stuff in drip feed) there's no need to keep up with the hundredths - until the clock stops, then it's displayed?

When the full requirements are documented, the pros and cons of different designs can be derived. So...for some more starters...
...how far apart from the master PICAXE to the slaves?
...how far apart are the slaves?
...electrically noisy environment? Nice 12v supply/nasty 12v supply?
...environmentally nasty environemnt?
 
M

mst

Member
Yeah sorry guys, the segments are made from lights driven by those triacs. The lights can keep up with tenths but not hundredths. So the data just needs to keep up with tenths and I will light all 7 segments of the 100ths while the clock is running and then when the clock stops send the 100th data to be displayed.

20 meters from master to first slave.
Slaves are about 1.5m apart
I can supply a very clean 12v
It IS a very electrically nasty enviroment. Imagine 20 cars with 44 amp magnitos screaming around in circles at 8000 rpm. However the cars are 30 meters away.
 
V

ValueAdd

Senior Member
Serial SPI type comms using the 74HC595’s is easy. Many here have done it .

The link that Westy gave to his 74HC595 based project includes circuit diagrams, layouts and code upon which you can very easily expand.

I can imagine however, that with 12 digits working as a form of real time clock that SPI comms via 595’s could prove too slow with 12 digits. You might need to split the digits into a couple of groups or go the multi PICAXE path that you have proposed.
 
L

lanternfish

Senior Member
Referring back to hippy's post #18, the picaxe per digit approach has the greatest merit. I do differ on the serial 'protocol' though. My suggestion is:

A frame is sent that ends with, say, 255. Preceeding this are the digits starting with 100ths, 10ths .... etc. And the frame is only sent when a digit changes.

Not explaining this very clearly, so as the 100ths changes frames are sent out that are the 100ths count 0 - 9 followed by the end of frame marker (255).

When the 10ths count changes the frame is 100ths, 10ths, 255; seconds change frame would be 100ths,10ths,seconds,255.

And so on. Provided of course that the total number of digits can be sent in under 1/100th of a second for the maximum number of digits.

And as you are only displaying 0 - 9 then a packed BCD byte would give 2 digits per byte sent.

Hope this provides food for thought.
 
W

westaust55

Moderator
I concur that the 74HC595 mehtod is likely not the way to go for this clock/timer based application.

From my observation with the project I first linnked to, with three digits being displayed, the best time I could achieve using an 18X to update the three digits continually was around 0.1 second.
 
You must log in or register to reply here.
Top