I think we're all just a bit confused on your goals. If you want to use a PICAXE, it will likely be too slow, regardless of how little you use it. You need fast reaction times and the PICAXE just doesn't have it. I was hoping that my last post would allow you to see you can simply use an AND gate in place of the PICAXE. This is a purely hardware solution, but I think it saves time and money in the long run and meets your goals.

If you really want to pursue a microcontroller solution, look at a PIC and BASIC software. Tracecom and I use PicBasicPro (PBP), but it ain't cheap. There is a free demo version of sorts that will work with certain PIC chips that would probably meet your needs - PBP turns BASIC code into assembly before going to the chip, so it can run, potentially, as fast as C and certainly faster than the PICAXE. Alternately, there is Great Cow BASIC (free) and at Oshonsoft that ErnieM recommends.

So, you can use a PIC and you can still write in BASIC. With a fast oscillator/crystal, you can do the timing on the PIC, but it might be easier to reference a dedicated real time clock (RTC) such as the DS1307 or similar. You can program in software debounce routines or simply use the BUTTON command, so that eliminates the need for a debounce circuit. The PIC would handle the logic, so no need for flip flops or logic gates. You could use the 74C926, but it could get messy depending on how you decide to send the clock signal. You could instead use something like the MAX7219/21 which will display up to eight digits per IC. The advantage here is instead of sending or feeding hundreds of pulses to the 74C926, you simply have the PIC determine what time you want to display once the finish line is crossed then push that value to the MAX7219/21 (won't see the digits rapidly advancing like you would with the 74C926).

Keep in mind this will take time and likely additional parts, so the choice is yours. Based on your experience and comfort level, for this specific application I would strongly suggest a purely hardware solution and avoid a microcontroller.

 

I won't guarantee this will work as is, but here is what I'm thinking of in place of the PICAXE. IC2 takes care of switch bounce and assumes once the limit switch is tripped, it stays that way until the next race.

IC1 is a 3-input AND gate. One input is the clock and is fed to all AND gates (one gate per track). One input is the limit switch which is also fed to all gates. The third input is tied to an IR pair through a toggle flip flop. In this circuit, I'm using a D flip flop as a T flip flop so once the car passed the IR beam, the output is latched to turn off the clock to the display.

This is a fast, rough cut and I leave it open for suggestions, corrections, or improvements from people far smarter than I.

I am trying to simulate this circuit in Multisim and I want to make sure that I have the conventions for the 7414 correct. Here is my understanding:

Pin DataSheet Yours
1 CLR R
2 D D
3 CLK CLK
4 PR S
5 Q Q
6 Q Q

Is this correct?

 

Yes. But you mean 7474.

 

I won't guarantee this will work as is, but here is what I'm thinking of in place of the PICAXE. IC2 takes care of switch bounce and assumes once the limit switch is tripped, it stays that way until the next race.

IC1 is a 3-input AND gate. One input is the clock and is fed to all AND gates (one gate per track). One input is the limit switch which is also fed to all gates. The third input is tied to an IR pair through a toggle flip flop. In this circuit, I'm using a D flip flop as a T flip flop so once the car passed the IR beam, the output is latched to turn off the clock to the display.

This is a fast, rough cut and I leave it open for suggestions, corrections, or improvements from people far smarter than I.

Well this certainly has possibilities. I put the circuit on Multisim and biased a NPN transistor on and off with a switch to simulate the photo transistor. It's been a while since I fooled with flip-flops so Multisim is a good way to observe what is happening. Here are the results:

The initial conditions are the timing oscillator is running, the START limit switch is open, and the 7474 CLK input is low and Q is high.

When the start limit is closed the output of the AND gate follows the output of the oscillator, however it seems that the voltage is attenuated down to around 2 volts. The start limit must remain closed during the duration of the race.

When the IR beam is interupted, the display stops incrementing, Q goes low and CLK goes high.

Once the car passes through the IR beam, CLK goes low and Q remains low.

Q will stay low throughout the start of the next race. In order to get Q high for the start of the next race you have to toggle CLK. Is there a fix to get around this?

 

The initial conditions are the timing oscillator is running, the START limit switch is open, and the 7474 CLK input is low and Q is high.

Good, this is as expected. When power is first applied, C2 acts as a brief short to ground, pulling the S input low and setting the Q output high. R5 then keeps the S input high for normal operation.

When the start limit is closed the output of the AND gate follows the output of the oscillator, however it seems that the voltage is attenuated down to around 2 volts.

Not sure about the lower voltage. I would expect to see about 5V out of the AND gate, but I haven't played with TTL in a while, so I may be wrong. Also might be something with Multisim of which I know nothing about.

The start limit must remain closed during the duration of the race.

This is by design and I *assumed* this is how the limit switch works. If not, we can add another flip flop if the limit switch acts as a momentary, not a latching, switch.

When the IR beam is interupted, the display stops incrementing, Q goes low and CLK goes high.

Once the car passes through the IR beam, CLK goes low and Q remains low.

Q will stay low throughout the start of the next race. In order to get Q high for the start of the next race you have to toggle CLK.

This is by design - the flip flop keeps the timer off once the car passes the IR beam. Keep in mind that the beam should be located such that it is only interrupted once. If, for example, the IR beam is low and is triggered by the passing of the wheels, the beam will be interrupted twice (front then back wheels) which will turn the counter back on. The IR beam should either be placed high enough off the ground horizontally so the body of the car only interrupts the beam once (this assumes all car bodies are solid) or vertically - though that presents its own challanges.

Is there a fix to get around this?

You can either cycle power or add a normally open (N.O.) momentary switch across C2. See below.

 

OK, you sold me. I am going to go with the hardware option. I’ll save my PICAXE experimentation for another day.


As far as the start limit staying closed during the duration of the race – that’s not a problem.


With regard to the lower voltage on the AND output, I can only assume that this is some kind of Multisim anomaly. I went back and looked at my old digital textbook and the truth table says that when all inputs are 1 then the output must be 1. Also the input waveform is identical to the output waveform.


The IR beam will be interrupted only once when the car passes through. We’re not going to rig up anything different or unusual. Between races we can either interrupt the beams again or simple cycle the power. The latter is easier. I added status LED’s to the circuit s that the race manager will know that the board has been reset. See attached.

 

Oops! I forgot to connect R9 and R10 to the 5 volt supply. I'll go back and fix the schematic.

 

Between races we can either interrupt the beams again or simple cycle the power.

You can add the switch SW2 in the last schematic I posted if you don't want to cycle power.

An ideal solution would be to have the circuit reset itself. I'm not positive it will work, but I've attached a possible way to accomplish this below. When the limit switch is reset, the output of the inverter goes from high to low. This is fed through a signal diode to a capacitor with a pull-up resistor on each side. The transition from high to low goes across the capacitor briefly, resetting the flip flop. The signal diode prevents voltage from the pull up resistors from feeding back into the AND gate. My only concern is how this will affect the flip flop on power up.

In any case, you'll want to feed a reset signal to your display IC's so they are reset to zero. Factoring this in, it may just be simplest to cycle power.

You could put two power switches in series - one a latching switch that turns power off permanently and a N.C. momentary switch you can use as your reset switch.

 

In any case, you'll want to feed a reset signal to your display IC's so they are reset to zero. Factoring this in, it may just be simplest to cycle power.

I agree that cycling the power is the simplest way. After each race the displays have to be reset to zero, then the race master sets the cars in the starting position (this opens the start limit switch) and hits the power reset. If all three LED's are lit, it shows that Q is high on all three flip-flops and the next race can start. The board will be in a plastic box with plexiglass cover so that the race master can see the LED's.

Thanks for your help and for talking me out of a lot of unnecessary programming headaches.

I'll post the display schematic and PCB layout in the next few days.

 

Here is the final schematic for the logic and timer board. I replaced the discrete crystal oscillator with an integrated crystal oscillator. The crystal I had was defective and replacements were scarce & expensive - even on e-bay. I also attached a Bill of Material and inter-connect diagram.View attachment Pinewood Derby Timer Diagram.pdfView attachment Timer-Logic Circuit Board B.O.M..pdf

 

Well, I’m back. Another Pinewood Derby racing season has come and gone. Recall from my earlier postings that the reason I began this project was that our existing display system didn’t work. Well, I fixed it using the knowledge I obtained from researching this project. I simply replaced the source LEDs and phototransistors with the following components:
http://optoelectronics.liteon.com/upload/download/DS-50-93-0018/P_100_E2872U.pdf
http://www.vishay.com/docs/81549/teft4300.pdf
And just like that, we got the system to display the 1st, 2nd and 3rd place finishers.
Let me bring you up to speed on what I’ve accomplished so far. To start with I was going to utilize a pure hardware solution as suggested by elec_mech. This was quickest and easiest. However, a hardware solution has so many limitations that I decided to have another look at a PICAXE solution operating at 32 mHz. The fact that the PICAXE could generate a 1 kHz clock signal clinched it for me. The system consists of a control module and three separate display modules mounted in a bridge assembly across the tracks. This ultimately proved to be very workable after experimenting with a number of different phototransistors and LED based IR sources. See the attached schematics. We tested the system using my breadboard version and it worked quite well actually, although in truth we didn’t get a lot of time to test the system because the overlords wanted to get the track set up for the race the next evening. Following the race event they were in a hurry to tear everything down. But the bottom line is it worked for half a dozen trials, but we used the repaired “order of finish” system for the actual event.
Now the scouting overlords think that I am some kind of electronic genius (if they only knew!) and they would still like to see the actual times displayed as well as the order of finish. In addition, they would prefer that the time of each lane be uploaded into an Excel spreadsheet at the end of each race. During this past weekend’s event, the order of finish had to be manually entered into a spreadsheet. The overlords are concerned that manually entering a four digit time for each race will take too long and be subject to errors. I honestly can’t say that I disagree with them on this point. So now I have a system that works (still in breadboard stage), was tested under race conditions, but the overlords are reluctant to use it because of the aforementioned concerns. That’s what I get for fixing the old system.
http://www.youtube.com/watch?v=nOncR6NBDAQ&feature=youtu.be

 

Thank you for the update. I look forward to studying your schematics in detail and seeing how I might apply this to other projects as well. Nicely done. For the PICAXE solution, is there more than one display, one per car, or did you just do a proof of concept for a single car? Would you consider posting the code? Nice job on the video too.

Regarding the overlords' request (demand?) to record times electronically, you have a few options.

• You could store them in the PICAXE's EEPROM and pull from that later.
  
• You can write to an external EEPROM IC and again pull the data later.
  
• You can write the data directly to a USB flash drive using the VDrive2. This would appear the most sophisticated to the overlords I think.
  

The first two options will require you to manually write down the data at a later time or you could connect to a computer and send the data to Hyperterminal and copy and paste that into a spreadsheet. It's been awhile since I've done any of that, so I may be giving the illusion of knowing more than I really do.

If you want to get swanky, you could add a PS/2 keyboard and LCD and enter in the names of each racer according to the track just prior to each race then store that information with the times to make it easier to keep track of in the spreadsheet.

 

Thank you for the update. I look forward to studying your schematics in detail and seeing how I might apply this to other projects as well. Nicely done. For the PICAXE solution, is there more than one display, one per car, or did you just do a proof of concept for a single car? Would you consider posting the code? Nice job on the video too.

Regarding the overlords' request (demand?) to record times electronically, you have a few options.

• You could store them in the PICAXE's EEPROM and pull from that later.
  
• You can write to an external EEPROM IC and again pull the data later.
  
• You can write the data directly to a USB flash drive using the VDrive2. This would appear the most sophisticated to the overlords I think.
  

The first two options will require you to manually write down the data at a later time or you could connect to a computer and send the data to Hyperterminal and copy and paste that into a spreadsheet. It's been awhile since I've done any of that, so I may be giving the illusion of knowing more than I really do.

If you want to get swanky, you could add a PS/2 keyboard and LCD and enter in the names of each racer according to the track just prior to each race then store that information with the times to make it easier to keep track of in the spreadsheet.

Hi elec-mech

I made a couple of minor corrections to the schematics and they are attached. As for the code, here you go:

'=======================PinewoodDerby.bas======================
'===Version 4.1===
'===constants===
'===variables===
　
Symbol Q_3 = PinB.0 ; rename input B.0 'Q_3'
Symbol Q_1 = PinB.1 ; rename input B.1 'Q_1'
Symbol SW_1 = PinB.2 ; rename input B.2 'SW_1'
Symbol Q_2 = PinB.3 ; rename input B.3 'Q_2'
Symbol Ln_2 = C.0 ; rename output C.0 ?Ln_2?
Symbol Ln_1 = C.1 ; rename output C.1 ?Ln_1?
Symbol Ln_3 = C.2 ; rename output C.2 ?Ln_3?
　
'===directives===
'#com3 'specify serial port
#picaxe 18M2 'specify processor
#no_data 'save download time
'#terminal of 'disable terminal window
'===================begin main program========================
setfreq M32 'run program at max speed
let dirsC=%11111111 'all outputs
let dirsB=%10110000 'change bits 7,5, & 4 to outputs
pwmout pwmdiv64, B.6, 124, 250 'produces a 1 kHz square wave
'output on pin B.6
;init: b2 = 0 ; reset targetbyte
; before the loop
main:
if pinB.2 = 1 then goto start ;limit switch closed to start race
goto main
　
myloop:
b0 = pinsB & %00001011 ;mask off bits 0, 1 & 3
if bit1 = 1 then LOW C.2 ;IR beam broken on Lane 1
endif 
if bit3 = 1 then LOW C.1 ;IR beam broken on Lane 2
endif 

if bit0 = 1 then LOW C.0 ;IR beam broken on Lane 3
endif 
if pinB.2 = 0 then goto main ;resets for the next race

goto myloop

start:
high C.0: high C.1: high C.2 ; output on
sertxd ("START RACE") ; send push message
goto myloop

As for the overlords, my answer is simply this:

What they are asking for is beyond the scope of this project. This is far beyond the capabilities of the PICAXE based system I have put together. It seems to me that what is required here (as was previously suggested to me by MrChips) is a PIC based system. Why? Because it can do a lot more things without getting bogged down by program execution. Also, it seems that the 74C926 is rather clunky technology and a microprocessor friendly MAX7219/21 would be a much better display driver as you have previously suggested. It would also adapt nicely with a MAX232 to communicate with the PC.
So it all comes down to this. I put a lot of effort into coming up with a workable system to time the races, but now it doesn’t fully meet the requirements of the end user. Where do we go from here? I will build the system as designed if they want it including the display bridge. If they don't want it then I will build a 2-lane version for my grandson's 'hot wheels' track. After all, what do you want for free?
I think I can figure out the circuitry required for a PIC version, but I’m clueless how to program the PIC. It was enough of a struggle for me just to get this simple PICAXE program to work.

 

Hmm, there is a chance a PICAXE can do this. PICAXE will communicate with a MAX7219 quite well since that is a I2C device. The MAX7221 uses SPI communication and while I've gotten it to work, I2C devices are much easier to implement (on the PICAXE). Imagine you could use the PICAXE to communicate with a PC through RS-232 if you chose, but I'd have to look into it. I still think using a USB drive with something like the VDrive2 would be slick - in this way you wouldn't need a computer while running the races, but having one would give piece of mind the data was being collected properly.

As you point out, the PICAXE's greatest limitation is speed which a big component of your project. A PIC would certainly do the job. You can program these in assembly, C or BASIC. Since you're comfortable with PICAXE's, I'd suggest BASIC. MicroEngineering Labs makes a nice BASIC compiler called PIC Basic Pro. The full version is not cheap, but you can get a student version for $50 USD that work with a limited number of PIC's. Among those is the 18F2550 which I imagine will do what you want nicely. There are other BASIC compilers to program PIC's. One you might look at is Great Cow BASIC which is free. I've never tried it, but it looks intriguing.

Thank you for the code and updates. If you decide to proceed with either a PICAXE or PIC, let us know and we'll do our best to assist. I have PBP, but I'm just getting back into it.

 

This is a project that I have been working on for some time. I’ve developed it on a breadboard and now I want to implement a working version on my grandson’s “Hot Wheels” test bed. Here is how it works. When the start gate is released it trips a limit switch which stays closed for the duration of the race. The cars roll down an incline and on to a straight-away, finally passing through the finish line. When the start limit switch is closed the timers begin counting milliseconds. When the cars cross the finish line, they interrupt an IR beam which stops the count.
Now I have everything working as it should EXCEPT, after the cars cross the finish line the display will suddenly change after a short interval. The first photo shows the display immediately at the end of the race. The second photo shows the display 15 seconds or so later. It should be noted that the display does not change gradually or incrementally. It counts pulses just as though a signal was dumped into it and then it remains stable. The jump can occur in Lane 1, Lane 2 or sometimes both lanes. The next post shows the schematics and a brief bit of development history.

 

When I first assembled these circuits on the PCBs, Lane 2 would continuously count even though the control pins on IC1 were reading 0.0 volts. Nevertheless, I suspected something was triggering these gates so I added 100 pF capacitors C8 & C9. That solved the problem of the continuous readout, but now the display was extremely sensitive to stray capacitance. If I brought my hand anywhere near the display, the control module or interconnecting cable, the display would start counting. However if I touched a common ground with one hand and brought the other hand near the display, it remained stable. So then I added capacitors C10 & C11. That cured the sensitivity issue, but brought me to my present dilemma. I have tried various values for C10 & C11, from 100 pF to 1 uF. The only thing that changing the value affects is the time delay from the end of the race until the display “jumps”. With the 100 pF the display will jump within a few seconds, while the 1 uF will take a minute or more before it jumps. It also affects the magnitude of the “jump”. For example, the 100 pF capacitor will result in a jump of a few hundred milliseconds, while a 1.0 uF capacitor will result in a jump of 2000 to 3000 milliseconds. The photos show the change with a 0.1 uF capacitor.
I’m sure I left out some pertinent information, but if anyone has any ideas I would sure appreciate it. Here is the code for the 18M2 processor. Ignore the 14M2 processor in the schematic. That is for a future enhancement (order of finish) if I ever get that far.
I can post the code if you think it would help solve the problem, but I think the solution is in the hardware and it's right under my nose but I cant seem to get my arms around it.

 

In studying your circuit and stated problems, the CD4066 seems to be the culprit. It may be due to the fact it is designed to pass analog signals and as a result is passing a type of switch bounce and/or is picking up and passing noise.

First, try replacing C10 and C11 with 10kΩ pull-down resistors. This should prevent the inputs to the 74C926 from floating when the clock signal is low or the control is off. You might also try putting a 0.01uF or 0.1uF capacitor in series between the CD4066 output and the 74C926 input with the pull-down resistor on the 74C926 side.

Failing all this, I'd suggest replacing the CD4066 altogether with a 2-input AND gate such as a CD4081. Feed the 1kHz signal into one input and the control signal into the other. You shouldn't need it, but it wouldn't hurt to keep a 10kΩ pull-down resistor on the output. This should give you a purely digital output without the worry about stray capacitance or switch bounce.

 

The 10k pull down resistors did the trick! Sorry I didn't get back to you sooner but I had a surgical procedure done and I wasn't up to going back to the shop until this morning.

I'll post a link to the video of this contraption working on the "hot wheels" track.

Al

 

Glad to hear it worked! I mean, not that I had any doubts in my suggestions . . .

 

Don't give up just because some people are cautious. Iron out bugs and maybe they will let you use it next season before the finals. They probably saw a few bugs and decided not to trust the system yet.

Also keep us updated as I'm sure others will want to try this circuit out!