You could look at GPS chips PPS (pulses per second) output. Something like GT-U7 can give upto 1khz PPS for the most common and cheaper variant, and upto 10Mhz for the elusive and expensive variant. Most GPS chips do not give any sort of access to this, i certainly haven'y found a way of accessing anything smaller than s from my phone - but then i haven't looked that hard
Data sheet:
91tuvtrO2jL.pdf (ssl-images-amazon.com)
This would give an accurate clock source and 40ns accuracy, providing you can get it to work with PICAXE
Every project that I have seen these used with, and used to keep track of time have used tempurature regulated crystals for the controller
Even if you use the PPS from the GPS into hippys' timing curcuit you have the tempurature variability of the picaxe itself. When you are getting towards the timing standards you are looking for a few fractions of a degree are going to make a difference and get you of your 1 in 100,000 target. It not even just the crystal itself, but the PLL circuit that is often used to get higher clocks from slower crystals.
As an idea I have been working another project using a AS5600 encoder
here is how I decided to be able to calculate things for RPM
Code:
/*
//clock1 = ARM_DWT_CYCCNT; //read system clock - disabled during micros testing
clock1 = micros(); //read micros() variable
ReadRawAngle(); //read angle from AS5600
clock2 = micros(); // read micros again
//clock2 = ARM_DWT_CYCCNT; //read system clock - disabled while using micros
Serial.println(clock1); //send before and after clock to serial monitor
Serial.println(clock2);
difference = clock2-clock1; //calcualte difference
Serial.println(difference); //print it
//using micro() we get 202 micros second to read angle over i2c
//using arm clock 121122 - 121253 cycles 0.00020187 - 0.000202088s @600MHz
//1rpm = 6 degrees a second
//0.00036 dgeree per m/s or or 0.07272 degrees for 202ms
//1,000,000us per second, 202 fits 4950.495045950 times
delay(500);
Serial.println();
*/
this line here is the most telling
Code:
//using arm clock 121122 - 121253 cycles 0.00020187 - 0.000202088s @600MHz
a variation of 31 clock cycles when continuously reading the same i2c device (and this was in tempurature stable room too). GPS can remove that, in theory, if you just read that data stream from the GPS chip, assume that each read takes same amount of time, providing you can find a GPS that will let you access the nanosecond scale. And then from the specs i have seen most don't get much below 20ns resolution. With that said i suspect you are going to run out of mathmatical space very quickly. The next section of that code, added up a set of reading and divided by the total number of readings taken to give an average output.
There is something else that cropped up while looking through various other timing thread on various forums, the rate that the I/O operated at, the chip used for the above although runs it core @600mhz the I/O runs at around 150mhz. I don't know if this withstands for interrupts or not but is something else you are goin to have to think about along side rise and fall times.
You may also need to defeat the PIC(axe)'s "Watchdog" which may kick in at about 2.3 seconds.