Joe_Keaveney

It's RC-Timing, unfortunately no doc yet for output, I have emailed Dale the programmer though.

I should also point out that the Arduino is running the SerialEvent() tutorial here - once the program is uploaded to the Arduino, you can close the IDE and open the RC timing program. The Arduino will continue receiving data on the USB input.

Joe_Keaveney

Hi all,

Well I took Phil's very good advice and hooked up my LCD display to the Arduino. Using the SerialDisplay() tutorial in the LCDDisplay library that comes pre-packaged with Arduino allowed me to read most of what the RC timing program was giving me, modifying the code slightly allowed me to scroll over a bit and see the rest of the output from the RC timing program.

Anyway, I've looked at the serial data coming out of RC Timing for the displays and it's in this format:

[<RoundNumber>:<HeatNumber>:<TimeRemaining/TimeElapsed>:1,2,:0,0,::]

Here's a video of what I mean

I know for sure that the Round Number is first, the Heat Number is second, the Time Elapsed is third. The ones that I need to be 100% on are the figures at the end. I think these are a) 1,2,: positions of the cars in the race (I only had two cars in the race), and b) 0,0,:the total laps of each car. A bit more testing should confirm this.

Another small step

Joe_Keaveney

A little more progress again.

The full format of the serial output from the RC timing program is:

Anyway, I've developed the Arduino code along the lines of the pseudo published on the blog, and so far I've processed the round number, heat number, and time elapsed information so it displays on my 16x2 LCD display (I'm using this display to test out the handling and processing of data, obviously the board I make will be using LEDs or something which can display brightly and is large enough to be seen from the other side of the track).

Video here: https://www.youtube.com/watch?v=K7GmfiHfxOY

Amongst other things on my list to do are:

1) Code the rest of the timing data handling (car1,carN,:laps1,lapsN,:improver1,
improverN,)

2) Build a small binary counter to test the 74HC595 shift registers I'm using for the 7-segment displays

3) Build a working full-size 7-segment display that uses the 12V DC supply I'm supplying the board with - 28 LEDs, 7 PN2222 transistors, 14 resistors, etc (Arduino gets 5V from the RC timing PC)

I've also got to decided how I'm going to get all the output pins I'm going to need if I build a board that shows the positions of every car in the race - I don't think the Arduino has that many output pins available (10 cars x 3 output pins per car). So I need a way to address each 7-segment display individually ideally.

Right now, I'm commenting the code I've done so far, and I'll upload it to the blog, and do a blog on the coding so far.

Comments welcome!

howardcano

iTrader: (37)

That looks like excellent progress, Joe!

Please forgive me if this is obvious, but when driving a bunch of LEDs, multiplexing is your friend. It can save huge amounts of hardware, with only a little software (and of course some reduction in brightness, which can be partially compensated by increasing drive current).

Joe_Keaveney

Thanks for the advice Howard, I'll read up on multiplexing, I barely remember any of my CompSci classes from university days now, I'm sure this would be a whole lot easier if I'd paid more attention

I'm looking at reducing the brightness anyway, as the board will be fairly power hungry if I run each led at full power!

How exactly do you get around the lack of pins though? I assume there's an intermediate stage circuit that I'll use to address the LEDs? Or is this possible with shift registers?

PDR

iTrader: (31)

Depending on your design, shift registers can turn a single pin into many. There's a tutorial here: http://www.arduino.cc/en/Tutorial/ShiftOut

Phil.

howardcano

iTrader: (37)

Phil is right: For a generating whole bunch of outputs while using only a few processor pins, a shift register is ideal, as long as it can be done quickly enough for the application. You can either twiddle pins directly, or use an existing synchronous serial port if the processor has one available.

If more speed is needed, then you could write multiple bits in parallel simultaneously to a latch, and address as many latches as you need. For byte-wide latches, that's 8 processor pins for the parallel data, and as many as you need to address the desired latch (for instance, 3 processor pins to select 1 of 8 latches using something like a 74HC138), plus a pin to do the write.

There used to be IC's specifically made to interface to a microprocessor and expand the number of IO pins, but they are probably ancient history by now. (But it seems like just yesterday to some of us!)

Multiplexing an 8 digit, 8 segment (7 plus decimal point) display requires one byte-wide latch for the segments, and one byte-wide latch for the digit select, plus any necessary buffers for the current levels involved. That's a lot of LED segments for only two latches (or no latches, if you have enough processor pins already available).

PDR

iTrader: (31)

Forgive me, it's been years since I've put hands on this stuff, but I forgot that there are IC's purpose-built for this kind of application. They used to be BCD-driven, but this one has an SPI interface:
https://www.sparkfun.com/products/9622

There are likely a whole bunch of others, but this one can drive up to 8 digits from a single IC

Joe_Keaveney

I think I'm starting to understand.

I was thinking of an array (for now, just imagine it to be 8 x 8) of transistors, the output of one shift register (the row shift register) connected to the base , the output of the other (the column shift register) connected to the collector (and load). The row SR provides the forward bas, the column SR provides ground. Would this work?

I still need to read up on multiplexing as yet.

howardcano

iTrader: (37)

If I understand correctly, yes, that will work, but it will only activate one LED at a time. While multiplexing, the maximum duty cycle of any given LED would be 1/64, which won't be very bright. Driving the segments byte-wide, but enabling only one digit at a time while multiplexing, will give a maximum duty cycle of 1/8, which is more reasonable.

Typically the LEDs can be driven harder while multiplexing (as opposed to continuous drive), since their duty cycle is low. That will help with brightness.

howardcano

iTrader: (37)

That's an excellent find! The drive current might be insufficient, depending on how many LEDs are used per segment in what I assume will be a fairly large display.

Wiring the LEDs in series can help reduce the total current required, but that would require operation from more than 5V if several are in series.

Joe_Keaveney

Hi all,

Probably out of a sense of mad curiosity, I'm going to experiment with a multiplexed LED array using 2 pairs of daisy-chained 74HC595s to act as a test-bed for the display hardware.

This will (hopefully) give me a 16x16 array (so 256 potential LEDs in all). With each LED representing a segment of a 7-segment display, this will give me more than enough segments to test the code for the board.

I'm going to draw up a table so I can see which matrix element represents which segment of the display (for example pin Q0 on shift register pair 1, and pin Q0 on shift register pair 2 might be Heat number segment A)

The final board will probably use higher-power shift registers, does anyone have any suggestions? If I'm only illuminating one segment at a time then the current would be ~80mA. I may look at illuminating more than one segment at a time (in order to increase the frequency at which the whole board is refreshed) if the brightness of the LEDs isn't sufficient or I may increase the current given the duty cycle of the LEDs will be very short. (I should have a look at the MM5450 as you suggested Howard).

EDIT: Actually, if I get a pair of 7219s as Phil linked to, that would cut out two 74HC595s? Would this work?

PDR

iTrader: (31)

You only need one 7219 to drive 8 digits of 7-segment displays (in fact, 64 separate pieces, if you count the decimal point) - it does all the work for you. No shift registers required.

According to the specs, it can drive 100mA through each segment and sink 500mA through the common cathode. If you're going to peak at 80mA, you won't need any extra driver hardware.

To your first question above, rather than use higher power shift registers, I'd move to driver transistors for greater scalability. As Howard suggested, I would even be tempted to go for a higher-voltage "LED stage" and use a current-limiting IC/circuit to string "N" LEDs in series to keep the current down.

Joe_Keaveney

I'm definitely coming round to the idea of using more specific-to-task hardware, the further I look into it, the more the sheer scale (and possibly tedium) of all those transistors and resistors dawns on me.

One 7219 won't be enough for the board I want to build.

I'm planning to build it in two stages:

Stage 1 - Round Number, Heat Number and Time Elapsed (7 digits in all)
Stage 2 - Race positions (Displaying car number relevant to race position - this will have a box labelled '1' that displays the number of the car that is currently 1st in the race, another box labelled 2....and so on) - (10 digits in all)

I might wish to add number of laps of the lead car at some stage also (3 digits).

Although I could do Stage 1 with one 7219, I wouldn't be able to do Stage 2. A board incorporating both stages will need a minimum 17 digits (119 segments). So I'd like to build enough 'spare room' into the system from the start to cope with my requirements for both stages.

Current-wise, I want to use 4 LEDs in series for each segment (from a 12V DC supply), so if I'm only lighting one segment at a time the current draw shouldn't be massive for common anode, although with 500mA for sink, I could theoretically light 4 segments at a time (320mA?) quite safely with common cathode?

What do you think is the most efficient design here? I need 17 digits minimum:

I can multiplex 2 pairs of 74HC595s (4 in total)
Could I multiplex 2 7219s?
How would a 'LED stage' work?

I know this is a lot of questions, but I'm learning as I go, most of this is already at the limit of my knowledge (although I hope I learn fast) so bear with me if there's any stupid questions here.

Thanks for your input guys, your advice is much appreciated!

howardcano

iTrader: (37)

That's why we're all here. Bouncing ideas off each other is a wonderful way to learn and to develop a design. Those of us who don't contribute ideas might still learn by observing the development process that you are documenting here. ( I have had several engineers say something like "I understand how it works when I look at the schematic; but how do you come up with the schematic in the first place?") This thread will be an excellent example of this process.

Using three MAX7219's will give all the digits you need, but one of their biggest advantages-- having all the high-current drivers built-in-- will be negated by the requirements to drive four series LEDs per segment, and to sink all of the segment currents at once (640mA, in this case), both of which will require external drivers. The remaining advantage of the MAX7219 is that it relieves the processor of doing the display multiplexing. But that might not be worth their cost, since the same thing can be done using much cheaper ICs and having the processor do the display multiplexing along with its other tasks (and it certainly seems to have the processing power to easily do so). Plus, I think part of the fun of the project will be writing the software to do the display multiplexing.

For the number of digits you need, splitting the digits up into two groups, one group of eight and one group of nine, would be reasonable. That will require one IC to drive the segments of each group (assuming the IC has eight outputs), or two ICs total. Then one more IC can handle the digit drive (although at least nine outputs are required for that).

For a common-cathode LED arrangement, you should consider using the venerable CD4000/74C series devices for the segment drive. They will run at 12V, eliminating the need to do level-shifting on the segment driver transistors. Level shifting will still need to be done, but it can be between the processor lines and the CD4000/74C logic, where there are fewer lines that need it if using a serial interface. One darlington NPN transistor (emitter follower) plus a current-limit resistor per segment (sixteen total) would be fine for the high-current segment drive buffers.

N-channel MOSFETS would be a good choice for the high-current digit drive buffers (nine total), as many exist that can be driven directly from the 5V logic level.

I can suggest particular IC part numbers for the above, but you might want to do the selection yourself. It's not difficult, and during your search you could discover other interesting ICs that might be useful for other, unrelated future designs. Serendipity is cool.