Edge detection - pulse generation

Hello
I'm after a bit of general advice on using CMOS for pulse generation.
I'm detecting a water meter magnet with a Hall device that has active low output (no magnet, output high)
This feeds into an XBee Series 2 on a battery which normally sleeps until the Hall wakes it up.
The meter can run fast or slow or the magnet can sit in front of the Hall for months at a time, so what I'm after is something to generate a pulse of known (ish) length, say 500-mS, to wake the XBee then let it go back to sleep.
At the moment, I'm using a 74HC14 inverting Schmitt with a capacitor in series with the input and a pullup resistor to Vcc - values of 1-meg and 0.1uF work well on the falling edge. Slow input pulses are not a problem.
The problem is that for very fast pulses, the Schmitt output pulse is also reduced in duration.
Is there something better than the 74HC14 that will give a fixed width pulse regardless of the input width? Realistically, the meter pulse width won't go much less than 50-mS, but I need the output longer to get the XBee up and running and warm up another sensor.
If I wasn't strapped for time, a small MCU would do the job, but I haven't set an AtTiny or similar for sleeping before and I don't have the time to do it right now.
Hope this explains it, no circuit drawing I'm afraid, but the Schmitt edge detector circuit is quite well known.
Thanks

Hello
I'm after a bit of general advice on using CMOS for pulse generation.
I'm detecting a water meter magnet with a Hall device that has active low output (no magnet, output high)
This feeds into an XBee Series 2 on a battery which normally sleeps until the Hall wakes it up.
The meter can run fast or slow or the magnet can sit in front of the Hall for months at a time, so what I'm after is something to generate a pulse of known (ish) length, say 500-mS, to wake the XBee then let it go back to sleep.
At the moment, I'm using a 74HC14 inverting Schmitt with a capacitor in series with the input and a pullup resistor to Vcc - values of 1-meg and 0.1uF work well on the falling edge. Slow input pulses are not a problem.
The problem is that for very fast pulses, the Schmitt output pulse is also reduced in duration.
Is there something better than the 74HC14 that will give a fixed width pulse regardless of the input width? Realistically, the meter pulse width won't go much less than 50-mS, but I need the output longer to get the XBee up and running and warm up another sensor.
If I wasn't strapped for time, a small MCU would do the job, but I haven't set an AtTiny or similar for sleeping before and I don't have the time to do it right now.
Hope this explains it, no circuit drawing I'm afraid, but the Schmitt edge detector circuit is quite well known.
Thanks

Hello
I'm after a bit of general advice on using CMOS for pulse generation.
I'm detecting a water meter magnet with a Hall device that has active low output (no magnet, output high)
This feeds into an XBee Series 2 on a battery which normally sleeps until the Hall wakes it up.
The meter can run fast or slow or the magnet can sit in front of the Hall for months at a time, so what I'm after is something to generate a pulse of known (ish) length, say 500-mS, to wake the XBee then let it go back to sleep.
At the moment, I'm using a 74HC14 inverting Schmitt with a capacitor in series with the input and a pullup resistor to Vcc - values of 1-meg and 0.1uF work well on the falling edge. Slow input pulses are not a problem.
The problem is that for very fast pulses, the Schmitt output pulse is also reduced in duration.
Is there something better than the 74HC14 that will give a fixed width pulse regardless of the input width? Realistically, the meter pulse width won't go much less than 50-mS, but I need the output longer to get the XBee up and running and warm up another sensor.
If I wasn't strapped for time, a small MCU would do the job, but I haven't set an AtTiny or similar for sleeping before and I don't have the time to do it right now.
Hope this explains it, no circuit drawing I'm afraid, but the Schmitt edge detector circuit is quite well known.
Thanks

Many thanks for all the suggestions.
Am I right in finding that the expected output pulse width is dependent on the input pulse width?
The scope tells me that the output varies in width until the input width is long enough.
My old CMOS books (Marston and Lancaster) suggest that any falling edge triggers the 0.7xCxR output.
All the usual precautions with unused inputs done, Hall works a treat (Infineon TLE 4913 for info, low power, SOT).
In testing, slowly passing the magnet over the Hall gives the expected results, but a fast pass sees the output pulse width reduce significantly.
In practice, the meter dial rotates fairly slowly (1-litre per rotation), so maybe only a catestrophic leak would cause problems with timing.
On a similar setup on the gas meter, where I have a PSU available, I use an Arduino to do the pulses - however, the downside is that any switching on the same circuit causes false pulses. RC snubbers on the switch contacts cures most of it, but only battery power gives complete isolation.

Replying to myself
This is a fool's rush in moment.
To quote from Doctronics site:-"Edge detector, or half-monostable, circuits are useful in producing control signals which you can use within a larger digital circuit. The most important limitation is that the period of the input pulse must be longer than that of the output pulse. Usually, you want a short output pulse. Choose R and C values accordingly."
This explains why the fast input pulses result in shorter than expected output pulses.
I was trying to get long pulses out from short pulses short pulses in.
Back to the drawing board or 7555. An MCU ultimately will provide the answer and for that I will look at the AtTiny 841 which I believe has the bonus of I2C.
What this is fundamentally all about is that XBee series 1 have a facility to "warm up" a sensor before transmitting data - series 2 do not.
By manipulating long and short output pulses, I could warm up a sensor, get the XBee woken up, and transmit data.
A valuable lesson