The solution in low end, PSOC 4 would be ~$2, the 5LP high end $ 4 - $ 10

PSOC 4 ARM Core M0, 48 Mhz
PSOC 5LP ARM Core M3, 80 Mhz

Learning curve, have you used an IDE before ? C or Verilog ?

Regards, Dana.

Arduino IDE ; and Processing 3 from Ben Frey

 

Here's a circuit which should do the job. Latency is the same as the pulse gap, i.e. 1ms. Replace R5 with a 100k pot if you want the gap to be adjustable.
View attachment 154178
V1 is the input pulse source. R1,D1 protect the circuit from excessive input pulse amplitude (given the automotive application). U1a just squares up the input pulses. Latch U1b gets set by the input pulse and reset 1ms later. R5,C3 set the pulse gap width. A regulated supply (e.g. 9V) is recommended for the circuit.
Attached is the LTspice simulation .asc file if anyone wants to play.
View attachment 154180

Thanks, looks interesting but cannot measure lengths, so I cannot check if it matches post # 20 requirements. Do you have the cd4000_v.lib.

 

Here's a circuit which should do the job. Latency is the same as the pulse gap, i.e. 1ms. Replace R5 with a 100k pot if you want the gap to be adjustable.
View attachment 154178
V1 is the input pulse source. R1,D1 protect the circuit from excessive input pulse amplitude (given the automotive application). U1a just squares up the input pulses. Latch U1b gets set by the input pulse and reset 1ms later. R5,C3 set the pulse gap width. A regulated supply (e.g. 9V) is recommended for the circuit.
Attached is the LTspice simulation .asc file if anyone wants to play.
View attachment 154180

'Do you have the cd4000_v.lib' was already asked but I cannot delete this post23.... since it also deletes #22

 

Something like This -

View attachment 154130

Timing resolution set to 1 uS. Could be much lower if needed.

PWM operated in one shot mode, eg, gen just one square cycle on trigger

Regards, Dana.

Any idea of the calculation time Dana, taking into account requirements described in post #20.

 

~ 15 uS. see attached.

Not optimized, used PSOC to gen its own test signal.
Have not tried out end limits of Pulse over Range yet.

See attached.

I looked at your spec, I thought you wanted a square wave out, slightly
lower period than incoming pulse ? In this setup its 4 clocks shorter,
read 32 uS.

The only time you get a square wave is when input is periodic, thereby
triggering a square every cycle of input.

Regards, Dana.

 

Do you have the cd4000_v.lib.

Yer tiz

 

~ 15 uS. see attached.

Not optimized, used PSOC to gen its own test signal.
Have not tried out end limits of Pulse over Range yet.

See attached.

I looked at your spec, I thought you wanted a square wave out, slightly
lower period than incoming pulse ? In this setup its 4 clocks shorter,
read 32 uS.

The only time you get a square wave is when input is periodic, thereby
triggering a square every cycle of input.

Regards, Dana.

I need a square wave after every P pulse but the length is based on the most recent interval of the P pulses - 1ms and - calculation time.

 

Maybe finally I am getting it, something like ph1 and ph2 relationship ?



Basically dead time insertion in PWM work. So you have a varying period
and you want a pulse train that is same period but falls inside the incoming
interval between pulses ?

If thats the case use a counter in PSOC to measure the period, update
the PWM period each time you measure incoming period, other settings
in PWM would be fixed, dead time width, etc.., and this process would
track the incoming signal.

Dead time insertion is a programmable, on the fly, mode in PSOC PWM,
as well as its period, duty cycle. I am sure in other UPs same capability.

Whats tricky here is latency because you have to use a period of incoming
to get the measurements and calcs for the next cycle to change. So one interval
goes by then the modified pulse output occurs. The calcs by the way done in HW.
All that is done is freq cntr period read then written to PWM.

Regards, Dana.

 

Maybe finally I am getting it, something like ph1 and ph2 relationship ?

View attachment 154268

Basically dead time insertion in PWM work. So you have a varying period
and you want a pulse train that is same period but falls inside the incoming
interval between pulses ?

If thats the case use a counter in PSOC to measure the period, update
the PWM period each time you measure incoming period, other settings
in PWM would be fixed, dead time width, etc.., and this process would
track the incoming signal.

Dead time insertion is a programmable, on the fly, mode in PSOC PWM,
as well as its period, duty cycle. I am sure in other UPs same capability.

Regards, Dana.

Hello Dana, My P-pulses are pulses, not sq.waves. After each P-pulse Pn+1 the previous interval between Pn+1 and Pn has to be evaluated and the one shot should fire as soon as the evaluation is accomplished (max 200µs after Pn+1) and the sq.wave length duration should be [previous Pn to Pn+1 interval] - 1ms - [evaluation time] ; and the 1ms should be adjustable in hard- or software. examples in post#20: where the interval is 5ms, the one shot fired afterward is (5-1ms - calculation time c) long.

 

Yer tiz

sorry I have to ask for the sym file..

 

Something like this, ph2 ?

 

Something like this, ph2 ?

View attachment 154274

Thanks Dana. Since my P waves are pulses the time should be measured from rising edge of the pulse and the one shot HIGH should end about 1 sec before the start of the rising edge of the next P pulse (this in the supposition that the interval hasn't changed.). Which of yr params defines this -1ms?

 

Thats dead time in clocks parameter in PWM settings, programmable.

But again the UP cannot predict when the next pulse comes (unless pulse train periodic) except to measure
one cycle, pulse to pulse, then act on the next cycle.

As stated earlier a number of ways to implement this in PSOC, I was just looking
at min HW needed to do the job with the more recent posts.

Regards, Dana.

 

Thats dead time in clocks parameter in PWM settings, programmable.

But again the UP cannot predict when the next pulse comes (unless pulse train periodic) except to measure
one cycle, pulse to pulse, then act on the next cycle.

As stated earlier a number of ways to implement this in PSOC, I was just looking
at min HW needed to do the job with the more recent posts.

Regards, Dana.

hello, can one simulate a row of pulses as in my post #20 in the PSOC IDE?
How much time is needed for the interval evaluation?

 

The interval, period, is just a counter with a gate. So answer is a simple read at end of gate,
a couple of uS. Earlier I found in screen shot that from end of second pulse to generating
the reduced period square to be ~ 15 uS, and I think with some more work could possibly
make that even smaller. Like Verilog solution.

Yes my test part of design can generate a fixed number or continuous stream of pulses.
Thats frankly quite easy. Or the whole design generating squares.

Regards, Dana.

 

The interval, period, is just a counter with a gate. So answer is a simple read at end of gate,
a couple of uS. Earlier I found in screen shot that from end of second pulse to generating
the reduced period square to be ~ 15 uS, and I think with some more work could possibly
make that even smaller. Like Verilog solution.

Yes my test part of design can generate a fixed number or continuous stream of pulses.
Thats frankly quite easy. Or the whole design generating squares.

Regards, Dana.

Thanks for all info Dana; this is an entirely new domain for me.

 

Here's a zip of the CD4000 (and CD4000_v) asy files:

 

Here is blown up example -



This will track incoming period so that generated pulse ends ~ 1 mS before
next incoming pulse starts as you stated

Regards, Dana.

 

An example at slower pulse rate in -



Regards, Dana.

 

Very nice Dana. Reaction time is very fast Can one analyse analog phenomena with PSOC? You have long experience with it. Is it sufficiently robust to function in automotive environment where air temperatures can go up to 100°C? Regards