Calculating Speed Using Puslin Command

[Gomsk4]

Hi All,

i am a AS student studying Systems and Control and am making a Speed Trap for a golf club, which displays the speed of the golfers swing to them. having never coded with basic (Only circuit wizard flowcharts) before and struggling to interpret other threads, i am looking for some help with calculating the speed using the PULSIN Command. at the moment my circuit consists of two Laser pointers that will shine directly on 2 LDR's. these allow me to detect when the beams are broken, which turn on and off a flip-flop. Therefore a pulse is received by the chip. if this isn't going to work, feedback is appreciated.

My main concern is the maths to calculate the speed. i looked at other threads with a similar topics but it was all a bit over my head (im a noob). my teacher explained to me the idea that PICAXE uses integer maths, but i still need a bit of help.
i am planning on using a distance of around 2cm between the beams because any wider and the PULSIN command will timeout i think? i will need to be able to record speed from around 10M/s to 80M/s to 1 decimal place at the least.

from other threads i have put together this code but dont know if it will work:

main: 
 symbol PulsePin = C.1
 symbol Pulse = w1
 Symbol distance = w2
 distance = 64000 
 Speed32 = w3
 SpeedQ= w4
 SpeedR= w5
pulsin PulsePin,1,Pulse
If Pulse = 0 
	goto main
End If 

Speed32 = Distance/Pulse 
SpeedQ = Speed32/32
SpeedR =Speed32//32
	
serout B.7,N2400,("Your Speed: " SpeedQ"."SpeedR " M/s")

i used 32 to scale the distance (0.02*10^5) as close to 65535 as possible. sorry for the long read. any help appreciated.

 

[Jeremy Harris]

Welcome.

I think your first issue is that light dependent resistors have a LOT of latency, typically around 5 to 10 ms, so are not well suited to measuring short time intervals. Also, the latency is temperature and light level dependent, so there is a potential source of variable, as well as fixed, errors.

I think you will probably need to look closely at getting the beam breaker part to work reliably over a wide range of light levels and temperatures, as that is going to be key to getting consistent time measurements. If it were me, then I think I'd look at using a modulated IR light beam, with an off-the-shelf demodulating detector, as that will remove all the effects of variable visible light in one go, and give you logic-level pulses that would be easy to work with. I don't think you need a laser for this, a focussed and modulated IR LED should work well enough, and be easy to set up and control.

Once you have a start pulse and a stop pulse, then pulsin should allow accurate measurements of the time interval between the two pulses, with a bit of playing around to get the output from the two sensors as a single pulse that starts when the first beam is broken and stops when the second beam is broken. With a fast enough Picaxe clock speed (64MHz) pulsin can resolve down to 0.635µs and measure a maximum pulse length of up to 40.96ms. If the swing length is longer than this, then reduce the clock speed, for example at the basic 4MHz clock speed pulsin will measure pulses as long as 0.65536s, but with only 10µs resolution.

I'm afraid I have no idea as to how long a golf swing is, but would guess that it might fall within the range of around 1/4 second or so, so it may well be that a Picaxe clocked at the standard 4MHz would be OK, and resolve time down to 10µs.

 

[Gomsk4]

Thanks for the reply, ill look into using Infra Red over visible light. would a IR filtered Phototransistor or Photodiode work? that most likely what will already be available at college.

using a quick google search, the average 150mph-50mph, which is around 67m/s, so using s=d/t i can get the time over 0.02m is 0.0002985 seconds. but that is like pro speed so using 44m/s gives me 0.00045. looking at this i will probably increase the distance between the beams.

if the pulsin command stores its time in 10us, then i will need to scale up the distance by 100,000 i think, then divide the distance by the pulse. Doing this using the 67m/s time: (0.02*100000)/29 = 68.96

In a previous thread (http://www.picaxeforum.co.uk/showthread.php?4863-Timing/page2) someone mentioned that you should try to scale the calculation up to as close as 65535 as possible before doing any final division. Is this to get a more accurate answer? and if not would i just divide the scaled distance by the pulse length?

 

[hippy]

80 metres per second = 2 cm in 250 us = 25 reading from PULSIN

10 metres per second = 2 cm in 2000 us = 200 reading from PUSLIN

The integer calculation is ...

Seed = 2000 / Pulse

Use 25 and 200 for the pulse value and that gives 80 and 10 as expected for metres per second.

Increase the 2000 to 20000 and that gives an extra decimal point value -

Speed = 20000 / Pulse

SpeedQ = Speed / 10
SpeedR = Speed // 10

So -

pulsin PulsePin, 1, Pulse
Speed = 20000 / Pulse
SpeedQ = Speed / 10
SpeedR = Speed // 10
serout B.7,N2400,("Your Speed: ",  #SpeedQ, ".", #SpeedR, " M/s")

 

[Gomsk4]

Thanks hippy. thats a lot clearer then what i had in my head.

if i was then to increase the clock speed up to say 8MHz, this means:

80 metres per second = 2 cm in 250 us = 50 reading from PULSIN

10 metres per second = 2 cm in 2000 us = 400 reading from PUSLIN

so if i was then to double the 2000 distance reading to 4000, then multiply by 10 and divide ect. this would give me a more accurate result?

 

[Gomsk4]

I think after a bit of testing it gives a wider range of results and therefore more accuracy. thanks for the help guys

 

[hippy]

if i was then to increase the clock speed up to say 8MHz, this means...

Exactly that. Note you have to double 20,000 to 40,000 for the one decimal place -

[b]setfreq m8[/b]
pulsin PulsePin, 1, Pulse
Speed = [b]40000[/b] / Pulse
SpeedQ = Speed / 10
SpeedR = Speed // 10
serout B.7,N2400[b]_8[/b],("Your Speed: ",  #SpeedQ, ".", #SpeedR, " M/s")

Note that the PICAXE only allows integers up to a maximum of 65535 so you cannot double again and use 80,000.

But you could multiply the 40,000 by 1.5 to give 60,000, and do the same for the bottom and the result is the same.

Then you could double the speed and halve the Pulse reading.

Speed = ( 40,000 * 1.5 ) / ( (pulse/2) * 1.5 )

Speed = 60,000 / ( pulse * 0.75 )

Speed = 60,000 / ( pulse * 3 / 4 )

Untested but I think this would be right ...

[b]setfreq m16[/b]
pulsin PulsePin, 1, Pulse
[b]Pulse = Pulse * 3 / 4[/b]
Speed = [b]60000[/b] / Pulse
SpeedQ = Speed / 10
SpeedR = Speed // 10
serout B.7,N2400[b]_16[/b],("Your Speed: ",  #SpeedQ, ".", #SpeedR, " M/s")

As you can see we are taking that initial 40,000 as close as we can to 65,535 to achieve maximum resolution. 40,000 * K => 65,535 then Speed = 65535 / ( Pulse * K / 2) or something like that.

 

[Gomsk4]

Pulse = Pulse * 3 / 4

Surely you cant multiply by 0.75 though, Basic would interpret this as 0 so then the pulse would just be 0?

You would therefore need to do (Pulse = Pulse / 4/3 ) and then to get this more accurate multiply by 100

so ( 100*Pulse / 400/3) then you can do ( Pulse = 300*Pulse/400 )

However if the pulse was any larger then 219 then it would exceed the 65535 limit?

To be honest i believe running at 8MHz and using that resolution would be plenty accurate for what i need, then i could increase the distance to 3cm instead of 2cm, as doubling that would give 60,000 rather then 40,000.

 

[AllyCat]

Surely you cant multiply by 0.75.

You can by using ** 16384 * 3.

Cheers, Alan.

 

[hippy]

I think some confusion has crept in; 0.75 = 3/4.

True; 'pulse = ( pulse / (4/3) )' in the real world of maths works but won't in the world of PICAXE integers and strictly left to right maths operations with no precedence. It's either -

pulse = pulse * 3 / 4 ; which may overflow

pulse = pulse / 4 * 3 ; which loses resolution

pulse = pulse ** 49151

That last one is the equivalence of real world (pulse*49151)/65536