well, here's my problem.


I've been revising/reworking an old project (might recognize it as the PIC Chronograph from another post)

it is now built with a larger microcontroller, and has a more sensitive 2 gate system.

in the programming, after the first photogate has been broken, the microcontroller will begin increasing a counter/storing #'s in a set of 3 registers.

these three registers will store the # in a decimal format. the first register for the 1ns place, the second for the 10ns place and the third for the 100ns place. (meaning it can only store a number at or below 999)

when the second photogate is broken, the counter will stop increasing this #.


the # stored in these three registers will be the amount of time there is between the breaking of the two gates.

the distance between the two gates is 1ft. it has been set up like this to help make the programming a little bit easier.

I need to somehow divide 1 by that # stored in the three registers so that I can have the device display the speed of whatever broke the two gates, but I have no idea how to do that using the PIC's instruction set.


I am programming in PICassembly using MLAB IDE

any ideas?

attached is the circuit diagram

 

(sorry, the image was invalid on the first message, so here it is again)

Attached Thumbnails

 

 

An idea: convert the 3 digit registers into a 16-bit integer then use a prewritten division routine. You'll have to scale '1' (1 foot I assume) to, say, 1000 to give you feet/us or else you'll keep getting 0 as a result.

A division routine is available here: dontronics.com (division.htm)

 

hi,
Its a basic elasped time measurement.
Use PORTB.0 as the start/stop Interrupt control for a an internal reg counter.

You can use one of the internal counters to give the required 'time' integer interval for the reg summer.

To simplify even further use a 3.768Mhz xtal [ or multiple] in place of the 4Mhz xtal.

Do you follow OK.?

__________________
Eric " Good enough is Perfect "
I will NOT answer PM's requesting technical help, please use the Forum
PIC tutorials: Nigel's www.winpicprog.co.uk/ Bill's: www.blueroomelectronics.com/

 

Or use a 16-bit hardware capture for better accuracy & less overhead.

He's dealing with metric time measures, so 4MHz is good (gives 1 us resolution)... I think there is a mistake in his above post; he must be measuring us, not ns.

Yes, followed by a basic conversion to speed through scaled reciprocation.

No, I don't.

 

Im puzzled why you are unable to follow my simple explanation.

My reply was intended for the OP's benefit, not so that you could go off in a childish Rant!.

The method I outlined is a well used way of doing exactly what the OP wants.

__________________
Eric " Good enough is Perfect "
I will NOT answer PM's requesting technical help, please use the Forum
PIC tutorials: Nigel's www.winpicprog.co.uk/ Bill's: www.blueroomelectronics.com/

 

I'm also puzzled. The way I read his post, he's after a speed, not time measurement.

Maybe. Well, at least my rant was concise.

Again, I thought he was after a speed measurement.

 

Hi dougy,
If he chooses the time 'int' correctly for his internal timers, he can finish up with a count proportional/equal to speed.

I am always happy to discuss with a fellow engineer the ways to solve a problem and I hope it will be that way with us.

But I dont need lessons in how to suck eggs.

__________________
Eric " Good enough is Perfect "
I will NOT answer PM's requesting technical help, please use the Forum
PIC tutorials: Nigel's www.winpicprog.co.uk/ Bill's: www.blueroomelectronics.com/

 

Last night, my partner for this project came up with an algorithm that will take care of what we need.

Say x represents the number stored in the register.
In the program we then have x added to itself a Q number of times until the result =y, or a number that is equal to/slightly greater than one. At the moment that x added Q # if times together is greater than one, your speed is given as Q.

It is only accurate in very high velocities and doesn't give decimal numbers (Q is a whole number) but we just make a second loop that goes into the tenth place or hundreth place. I'm not quite sure how to explain it here, but i've tried it through my partners explanationm and it works.


Thankyou guys for your help, but I can't modify the circuitry any more as I already have a PCB ready and waiting for the components to arrive in the mail.

If anyone else has any suggestions I'd be glad to take them, but unless there is something that will work much better than our algorithm posted here, the programming will use what my partner came up with.

For dougy83 and ericgibbs:

I appreciate the help, but niether of the ways posted here I will be able to use as the circuit above here is final.

Also, before this thread becomes an argument over which way is better, please reconsider the reasoning on why you are posting. Such as: is it really necessary to argue with someone I've never met before over the internet?
Please don't take offence to this, I'm just saying what needs to be said before stones are hurled at each other.

 

Some links on PIC math functions should help? Did i get this correct?

PIC routines

__________________
And on the eighth day God said, "Okay, Murphy, you're in charge!"

www.pcbheaven.com

 

I have no idea what you mean. I'm sure it's obvious to you, nevertheless.

I would never propose to provide tutition on such things, it's certainly not my area of expertise.

Hardly. Sorry if I upset you two.

 

Yep "inversion by addition" is how I would have done it. By simply choosing the correct value for Y (the destination) you scale the result, so you can use different values of Y to give a result in FPS or m/s etc.

Once you have the first decimal digit you get the remainder, multiply the remainder by 10 and just do it again to get the second decimal digit. Etc for more digits.

It's not that fast as a calculation but it is pretty "bulletproof" hehe get the pun?

 

Could you please explain how this is done. Thanks.

 

Ok, let's say the detectors are 1 foot apart, the bullet goes through and you get an elapsed time period of 253uS. To convert from a period to a speed (like feet per second) you add X to itself until you reach Y (which is 1 second or 1000000uS).

So;
Add X to Accumulator until it reaches 1000000;
(it is added 3952 times, reaches 999856)
the remainder = 144
so feet per second = 3952 and (144/253)

Now if you need the result in metres per second, you just use a different Y value, so instead of Y=1000000 you use a new Y=304878.
(feet/metres = 1/0.304878)

So use the same hardware, and same calc code but just with the new destination Y value;
Add X to Accumulator until it reaches 304878;
(it is added 1205 times, reaches 304865)
the remainder = 13
so metres per second = 1205 and (13/253)

Obviously the remainder can be processed with a similar "addition division" to the main calc.

I hope that answered your question? You see that the same hardware and excactly the same code can give the answer in FPS or M/S, and the code is very compact and brutally simple, just a loop and addition, although it is slow time-wise (which doesn't matter at all for this app).

 

hi Roman,
Thanks for answering, you beat me too it.
As you have clearly explained, its a standard solution for this problem.


dougy.
Reading some of your other thread posts, I suspect the real reason you are asking me is so that you can play some kind of childish tit for tat game.
I am old enough and wise enough to know when someone is trying to jerk me.

So I will pass on answering your question at this time, I have better things to do.

I will however, put the request for a reply on my job list, right after the one where I have to tidy my sock drawer, then I'll get back to you.

__________________
Eric " Good enough is Perfect "
I will NOT answer PM's requesting technical help, please use the Forum
PIC tutorials: Nigel's www.winpicprog.co.uk/ Bill's: www.blueroomelectronics.com/