Two triggers for timer

[Bryang]

Hi all
I have a little project I have been working on, on & off for a month or so...
I am counting the number of cars passing a given spot (either direction) and recording how many pass at each speed. Also, if they go too fast, they are beeped.
Basically, it works... 98% of the time!

OK, I have 2 lasers on one side of the road 1/2 a mtr apart, and 2 NPN photo resistors on the other side of the road, 1/2 a mtr apart also. When a beam is broken, I get a high signal.

What I have at the moment is an 08M waiting for either laser trigger, when one beam is broken, it puts an output pin high, then waits for the other beam to be broken, and when it is, switches the output low again. I then have an 18X waiting for the high from the 08M, per a pulsin. Once it has a valid pulsin time, the 18X calculates the speed, adds a count to the EEPROM, displays the data on a 16x2 LCD & toots the horn via a relay once for every 10 kph's above the speed limit, then waits for the next car.

As I said, it is fine 98% of the time. I think I'm getting poor transitions from high to low on the 08M, but as it is intermittent, it's hard to track down! and it's worse the further away the laser is from the photo transistor! Also, Daylight vs night testing doesn't seem to make much difference to the intermittent nature of it, as I had expected it might, so it's left me scratching my head!

I had been wondering about ditching the 08M & trying something like op-amps?? in place of it?? but before I do I thought maybe some suggestions from the forum might help either to improve the signal to the 08m or suggest something in it's place??

          ---------o----------+5V------------o
                   |                         |
                   |                         |
                  .-.                       .-.
                  | |10k                    | |10k
                  | |                       | |
                  '-'       .-------.       '-'
                   |        |  ???? |        |
                   o--------|o     o|--------o
                   |        |  ???? |        |
                   |        '---o---'        |
                   |            |            |
                 |/ NPN         |          |/ NPN
                -|  Photo       |         -|  Photo
                 |> Transistor  |          |> Transistor
                   |            |            |
                   |            |            |
                  ===           |           ===
                  GND      .----o---.       GND
                           |   18X  |
                           | PICAXE |
                           '--------'

Hopefully this displays OK!

 

[Dippy]

Lasers, don't tell Stan!

To check quality of transitions you can't beat a 'scope. Then the sentence "I think I'm getting poor transitions" turns into "I'm getting poor transitions" or "its perfect therefore something else is awry".

Could it be alignment? Or wobbly posts? Unless you have lensing on the receiving side your alingment must be bang on with, I assume, pin-point laser.

At first I thought it might be an ambient light issue, as photo-transistors could switch when the background light gets too bright - this is why most sensing in difficult situations is done using Photodiodes and modulation with a demodulator arrangement or missing pulse detection.

 

[sghioto]

Bryang,

A 98% success rate sounds pretty good for such a simple circuit. I like the simplicity of the photo transistors. What type of lasers are you using? Suspect the inexpensive handheld red dot pointer. I would just make sure the alignment is "dead on" and shield the transistors from ambient light as best as possible.

Steve G.

 

[Bryang]

Well, 98% is probably more like 95% on a good day;-)
Yes, the lasers are the key-ring red dot laser type, mounted (the hot glue gun is a wonderful invention )to to a sturdy frame. Similar for the photo-transistors, but they are separately mounted inside small jiffy boxes about an inch deep, with a 3/8" hole to let the light in. No lenses (I'd wondered if this would help or make it worse by magnifying "stray" sunlight, but not tried it yet!). To adjust the aim, or rather the receiving point, the jiffy boxes have a magnet on the back, and they can be easily slid on the steel plate on the receiving frame, but stay put once tweaked into position, then fly-leads to the rest of the circuitry, battery, etc.
"...Photodiodes and modulation with a demodulator arrangement or missing pulse detection..." Hmm OK, sound good - I'll have to do a bit of homework on this one!.
I expect(ed) you are right & need to go to basics with looking on a scope or similar at the quality & strength of the signal... so I'll have to beg, borrow, or steal one & learn how to use it!
I'll get back into it tomorrow afternoon & see how I go.
Thanks, Bryan.

 

[hippy]

The first thing you have to do is identify what the problem is ( you say it doesn't work always but you haven't described what doesn't happen or how it fails ), work out how that comes about and then design around the issue.

You have to also determine if the problem is with the laser hardware, the 08M hardware interface or software or the 18X software. You use PULSIN to measure the 08M pulse ...

Assume no traffic so the 18X's PULSIN timesout, you check the time, find it has timedout, throw it away, start another PULSIN ... What happens if between the timeout and starting another PULSIN a car enters the detection zone ? The 08M will have initiated the pulse but the PULSIN won't see it because it's waiting to see the leading edge of the pulse which has already happened before starting the PULSIN.

While it seems unlikely that cars would enter the detection zone at such a critical time, it's entirely possible you could miss every car passing through the detection zone. My rough guesstimate is you would miss 1 in 10,000 cars that way, but Sod's Law can lower those odd's drastically.

Writing to Eeprom and LCD also takes considerable time so that gives an opportunity for another car to enter the detection zone while dealing with those and it too will be missed.

To reduce missed vehicles to a minimum you may need to have multiple PICAXE's alternatively monitoring for PULSIN and another PICAXE taking their results and updating Eeprom and LCD. A commercial system would normally put its data in buffers so there's minimal chance of things being missed while allowing the buffers to be emptied at a more leisurely pace. You could probably achieve that with an I2C network of 28X1's but that could be overkill. It may be easier to just say that the percentage of missed cars is acceptable.

Working out how a system can fail comes under the grand heading of "Failure Mode Analysis"; work out what could go wrong, then what could cause that.

I assume that you're not doing this in the UK as this would likely be illegal on a number of counts related to the use of lasers and being an audible warning device.

 

[Dippy]

All the "modulation..." stuff is really where the signal isn't much higher than ambient and it's easy to separate the AC and DC component and amplify. Signal to noise etc.

If your system is abs rigid and abs lined up then a laser dot on a photo-transistor will be very intense so I can't see a weak signal being a problem.

Question to anyone: If the incident light on a photo-t is highly intense does it affect it's switching off time very much when the beam is obstructed? If so, you can get photo-ts where you can bias the base to change performance. I've never tried it so probably barking up the wrong tree and you'll find it's something totally different like a low-flying runner bean or your code misbehaving.

I think I'd be tempted to replace the 08M with logic and feed that to the 18X.

PS. If you had a scope you could nail whether its at the 08M end or the 18X end in a few minutes.

PPS.
1 in 10,000 hippy? How did you get that? He could miss a whole lot more if his PICAXE is busy Beeping and another car comes along

 

[Bryang]

Two triggers for timers

Hi
I think your all really saying is that I'll just have to work my way thru it!

I'm doing this on private land (2000 acres!) in Aussie - one of my responsibilities on site is traffic management, and after 5 years of people speeding around the car parks & road ways & me trying to spot them & tell people off, it hasn't made any difference, so I'm heading to the "shame" approach where for every 10kph too fast, the horn blasts, so everyone around the area turns & looks at the culpret... 2 blasts = 20k's over, etc;-)
Each time there is a trigger event, I increment the relative EEPROM loc'n in the 18X relative to the bracketed speed, so I can look at trends to see if this actually works to slow people down!
The two frames are portable but sturdy, and weighted down when in place.
The car numbers aren't that great, & missing the odd car isn't an issue, so deviating to write to the LCD, toot the horn, etc I'm ok with. FYI, Here's the 18X code for timing out on the PULSIN...

look_for_trigger:			

'When there is a laser beam present onto the photo-transistor, it 
'has a 0v signal to the picaxe, and goes high when the beam is broken.

	w6 = 0		'resets PULSIN time period to 0, 
	b4=0			'and resets speed to zero
	if pin6=1 then	'if pin-6 is aleady high (eg: laser missing target or
		pause 100	'something blocking target still) then pause until clear
		goto look_for_trigger	'so PULSIN gets a transition
		end if
													
	pulsin 6,1,w6	'counts while input in6=1....times out after 0.65 secs!
	if w6=0 or w6 > 65530 then look_for_trigger	'If puslin times out, loop again 
	
	write 15, b13	'writes most significant of W6 PULSIN to the EEPROM 
				'(location 15) for later use for LCD
	write 16, b12	'Writes Least sig fig to EEPROM to loc'n 16
	goto calculate	'if pulsin time is valid, go and calculate the speed

and anything under 3kph will overflow the pulsin too, & I have that under control (I think).

What it seems to do is at times, breaking the beam doesn't appear to give a high signal to the 08M, or at least it isn't relaying that to the 18X, and then it seems to lock up!

Hippy, thanks, you are right again - I just have to get in and check out what it's doing (or not doing!) ... properly!!! A magic fix would be nice, but they are rear beasts;-)

Dippy, you mention to replace the 08M with logic... more specifically, what came to mind? (in case I go this route?). I should stick with what I have until at least I know what's going on, but interested to consider another approach later maybe

Thanks.

 

[hippy]

1 in 10,000 hippy? How did you get that? He could miss a whole lot more if his PICAXE is busy Beeping and another car comes along

Actually I was a factor of 10 out. From first principles ...

Do
  Do
    PulsIn pin,state,w0
  Loop Until w0 <> 0
  Gosub FireAntiCarMissileIfNecessary
Loop

PulsIn times out after 655360uS, guessing the "Loop Until" test and restarting PulsIn takes 600uS, that's a ratio of ~1000 to 1, so if all things were equal, of 1001 cars, 1000 would pass through while in PulsIn, 1 while in the 'Loop Until'.

From a 'clean slate' completely empty road, 08M ready and waiting for a speeder, that's a 0.1% chance of driving through the detector and not being detected.

Things won't improve at 8MHz or even faster because it's a ratio issue.

Once a vehicle has passed the chance of missing cars following quickly behind is greater.

 

[Dippy]

All this being the case then, it would seem obvious that if the 95% success rate is when it's busy and 100% when it's not would suggest that it is a traffic rate problem and not physical detection going daft.

Equally obviously, if the device is busy beeping/flashing then it can't detect another vehicle, or half-detects another vehicle and gets itself in a twist until pulsin can timeout and start afresh.... possibly missing more vehicles if they're driving in a Conga.

All thats been said so far is that it gets worse at a longer distance..

For a start you could give the beeping job to another PICAXE. PICAXE 18X sends it a blip and can immediately return to its job. Maybe use the 08M - as I can't understand why you need 2 at the moment to do this simple task.

You've got some work to do to nail this one Bryang. Youv'e got the situation and the hardware and the software.. all we've got is a good imagination

 

[hippy]

@ Bryang : Comparing your code in post #7 to my example in #8 you have a fair bit of excess overhead which will reduce the time spent in PulsIn against time not in PulsIn.

You don't need to zero w6, b4 can be set just the first time you enter the loop ( or after ), the PulsIn will reject the pulse anyway if it's high to start with so the Pin6 test is redundant, the timeout / under-speed check can be two separate tests to restart the 'look for trigger'. With that in mind, I'd change your code to ...

Look_for_trigger:
  Do
    Do
      PulsIn 6,1,w6
    Loop Until w6 > 0
  Loop Until w6 <= 65530 
  write 15, b13	
  write 16, b12	
  b4 = 0
  Goto Calculate

 

[Bryang]

Thanks hippy,
your code does look much cleaner
FYI, I thought last night of tweaking the wiring on my circuit board so that I effectively split the signal to the 08M pins to also go to 2 READADC pins on the 18X then on switch-on, I can run through a subroutine to get the best signal/aim, per showing two bar graphs on the 16x2 LCD, so will try that tonight. At least I can set a starting point with the laser aim/signal strength, and can recheck easily "in the field".
Bryan.