Getting PULSIN to start consistently

Lloyds

Hi all,
This is a continuation of my NAND gate question . The NAND gate is working fine, BTW.

I am trying to time an event from the NAND gate with the PULSIN command with a BS2p40.
After the PULSIN command is initiated, there are 52ms allowed before the event must start, and then it must end within 52 more msec.

My problem is initiating the PULSIN command within 52 msec before the event's occurrence. I have tried this code:

DO UNTIL timer > 0 ' loop until the timer pin goes high
PULSIN timer, 1, timerpulse
LOOP
DEBUG

The problem with that seems to be that "timer" can go high anytime during the loop and the results will either be inaccurate, or the event will be missed altogether. The actual event time is about 500 microsec.

I have another input pin that I can use that goes high immediately before the "timer" goes high, so I tried the following code, using "prestart" to turn on the PULSIN command. The problem is that the event to be timed occurs about 20 micro sec after "prestart" goes high. Unfortunately, POLLWAIT takes 250 micro sec to turn on PULSIN, and by then the event is already over.

Any ideas on how I can get PULSIN to accurately time this event?
Thanks,
Lloyd

DEBUG CLS
DEBUG "waiting for event", CR
Beginning:
INPUT 13
INPUT 14
prestart PIN 13
timer PIN 14
timerpulse VAR Word
timerpulse =0
POLLIN prestart , 1 ' waiting for prestart pin to go high
POLLMODE 2
POLLWAIT 8 ' keep polling until prestart goes high, then proceed to PULSIN
PULSIN timer, 1, timerpulse
DEBUG " timerpulse ", DEC timerpulse,CR ' timerpulse is the value I am trying to capture
PAUSE 10000
GOTO beginning

Mike G

This command waits for the timer pin to go from low to high then it measures the high pulse.

PULSIN timer, 1, timerpulse

If the timer pin can go high for no reason, then I'm not sure how you would know the high is ever valid. Do you need a pull down resistor?

Or maybe just remove the DO UNTIL timer > 0 loop because

PULSIN timer, 1, timerpulse

waits for a transition.

Lloyds

Mike,
I don't think I stated that clearly. The timer pin is normally low, but at any time it can switch to high, and I need the PULSIN command to be constantly POLLing the timer pin so that the High interval of the timer pin can be measured. The timer pin doesn't go high by mistake, it's just that it is hard to predict when it will actually go high.

Sorry, but that still sounds confusing. Think of being at a track meet and having to time whoever comes by, but not knowing when they will appear.

Thanks,
Lloyd

Mike G

I'm confused...

PULSIN timer, 1, timerpulse

Just sits there and waits for a low to high transition.

So, why not...

Main:
  PULSIN timer, 1, timerpulse
  'do something if timerpulse is not 0
GOTO Main

Lloyds

Mike,
that will put it in a loop until the timer pin goes high, which is fine. But because the GOTO Main instruction takes some small amount of time to execute, wouldn't that mean there is a very short dead period in each loop when the beginning of the pin's high interval might be missed?

I don't know how the execution timing works.
Thanks,
Lloyd

Mike G

PULSIN times out after 49.151 ms, the max measurable pulse width for the BS2p. GOTO will be pretty quick, under 2.849ms (49.151 + 2.949 = 52 ms). Unless, I'm missing something... You are trying to measure a pulse, right?

DEBUG " timerpulse ", DEC timerpulse,CR ' timerpulse is the value I am trying to capture

Lloyds

Mike,
Correct. Yes, I am shooting thru 2 IR emitter/ detector pairs. These are connected to a quad NAND gate (see my previous post). The NAND logic is set up so that the pulse goes high as the first beam is broken, stays high, and then doesn't go low until the 2nd beam is broken. Basically, a speed trap.

I just tried the

DO UNTIL timerpulse >1
PULSIN timer, 1, timerpulse
LOOP

and seem to be getting fairly consistent results.
The time interval using the BS2p is around 645, which multiplied by 0.8usec, makes .000516 sec.
Like I said before, my concern is during the loop cycle because my actual timed interval is less than 1 msec.
It seems to be working, though.
Lloyd

vaclav_sal

Lloyd,
how about just detecting the change and than measure your pulse?
I do this ( just skeleton code) to detect WWVB leading edge and than do timing elsewere.



Scan:
New = INA.BIT0
Change = New ^ Old
IF Change THEN
GOSUB Process
ELSE
Old = New
GOTO Main
ENDIF

END




But my :pulses" are in order of 100's ms, that may be too long for you.
Vaclav

erco

@Lloyds: Just curious, you are after high precision timing here. You said you couldn't afford POLLWAIT because it introduced a 250 microsecond delay and your event is over (bullets in flight?). Is there any measurable delay associated with your hardware NAND gates, and if so, perhaps it will self cancel (start delay=stop delay) ?

Lloyds

Erco, I will add a sketch tonight to clarify the setup. That may help other ideas to surface.
Thanks,
Lloyd

Lloyds

vaclav,
Let me give that a try. I think the total time of the event is compatible, so it will depend on whether the repeatability and resolution are good enough.

Total time is around 500 usec, and resolution needs to be about one usec. I'll be back this evening.
Lloyd

Lloyds

Hi all,
I appreciate the input and feel like this is pretty close to resolution. I hope the upload went ok, I've been having a few technical difficulties.

I've attached an event time line to show what I am trying to do.
The Real goal is to accurately measure the length of Pulse D. I am using a 2p and the PULSIN resolution is 0.8usec, which is about what I need for this to work correctly.

Pulse D is on Pin 2 and is actually a spike at Event B and at Event C, which I have used a logic gate to convert to a pulse of duration D. Maybe just the 2 spikes can be used, I don't know.

I also have Pin 1 which gives a High spike at Event A about 25usec before Event B occurs. The interval between A and B does not need to be measured, but maybe Event A can be used to signal that Event B is about to occur. That may or may not be useful

So, how do I consistently measure the length of Pulse D? It has to be repeatable.
Any ideas?

Thanks,
Lloydevent map.pdf

PJAllen

You could trigger a one-shot with a/another sensor placed before your
start sensor.
Its output would hold true after its triggering event, allowing your test to
fall through to the PULSIN (start.)

So, it'd stay at a line like --

Test:
IF Trig_1shot = 0 THEN Test


' and then


Time_It:
PULSIN...

You'd position the 1shot Trigger so that the time event
will hit within the PULSIN limit.

Does that make sense?

Lloyds

PJ,
Would that require a loop to work? Is the one-shot like a logic gate?

I have tried loops to detect when the single Event A went high and they have not been reliable. The high spike for event A is only about 6 usec, but I do not have a scope to check the actual duration.
I have gotten this code to reliably detect the Event A spike:
POLLIN eventA , 1
POLLMODE 2
POLLWAIT 8

I then have it turn on PULSIN, but there is a lag of up to 250 micro sec from the POLLIN and I only have 25 usec before PULSIN needs to start counting.
I seems like I need to move the Event A sensor farther away from the pulse detectors to get enough time for the lag between the events.

With a DO LOOP, I wonder what the shortest event it can reliably detect is?
Is this information useful for? http://www.emesys.com/BS2speed.htm I am not sure I know how to interpret it.
Thanks,
Lloyd

PJAllen

Yes, it's like a logic gate. Look up a 74HC123, it's a dual one-shot. It can be config'd to trig on a hi-going or lo-going transition. The pulse-width is set with a resistor and a capacitor.
Yes, you'd still have to test it with a loop, you can't escape that.

I was figuring that this was a model car timer or something like that. So, my one-shot idea was to set up a primer for the PULSIN, in effect, being Triggered it'd signal - "Get Ready, 'cause here it comes!" (Assuming that the ensuing PULSIN event would always effect before exhausting the PULSIN max wait pd.)

I know that an SX28/48 (with a 50-75MHz osc) could shred that loop/test situation to be negligible.
The Propeller runs very fast indeed and I wouldn't be surprised if it couldn't clean up on that - in PASM for sure, but SPIN I'm pretty sure, too. You can get a Spin Stamp for $29.99! If you decide to take this on with a Propeller, I highly recommend that device. (You could do away with the RS latch circuitry, too.)

Many of the members over there in the Propeller Forum could likely address this more authoritatively than I provided that you furnish all the specifics.

Lloyds

PJ,
I think you've pretty well nailed it. Just taxing the speed limits of the stamp. I think I can still fiddle with the spacing of the sensors to get this to run properly, but moving to a faster device is the way to go.
Let me tinker some more.
Thanks,
Lloyd

vaclav_sal

How about this for an idea

Hardware
Use input RS flip flop ( 2 NAND gates) to detect event A - leading edge

Software
DO
LOOP WHILE event A not detected
event A detected
wait for event B
PULSIN ....
wait for event C
PULSIN...
run your process
reset input RS FF

Vaclav

Lloyds

Vaclav,
Yes, I see what you mean. You are basically changing Event A from a very tiny spike to a pulse that lasts from Event A to Event B. That should work, and I bet it would respond very quickly.

What I ended up doing was moving the sensors for event A away from the sensors for event B to give a minimum spacing of 250 usec and then used the POLLIN code below. But I bet your method will respond faster and I will be able to move sensor A back to its original location (or close to it). That will allow me to make the entire set of all three sensors more compact.

Lloyd


This code worked after I increased the space between sensor A and B (as shown in a previous post):

DEBUG CLS
q VAR Nib
q=0
DEBUG "waiting for event 1", CR
Beginning:
AUXIO
INPUT 13
INPUT 14
getready PIN 13
timer PIN 14
timerpulse VAR Word
timerpulse =0

POLLIN getready , 1
POLLMODE 2
POLLWAIT 8

PULSIN timer, 1, timerpulse
q=q+1
DEBUG " Event # ",DEC q ,CR
DEBUG " timerpulse ", DEC timerpulse,CR
' timerpulse = 598760/timerpulse (I have to fix the division problem)
DEBUG " velocity ", DEC timerpulse,CR

PAUSE 1000
GOTO beginning

vaclav_sal

Technically - the overall response to event A is still determined by the DO/LOOP. But the actuall event A detection is the NAND propagation time and depending on technology used generally measured in ns. As far as reseting the input RS FF it is your call - on event B or C.
If you need detection of repetitive event A ( AK47 rate of fire is ???) you could reset it as soon as event B is detected.
I think you said you need to know the pulse between event B and C, but using input RS FF will aslo give you "pulse" ( minus 1us) A to B as bonus.
Vaclav