No, it doesn't work at all.
First problem: Code is incomplete and does not compile at all.
And the next problem is, that you start for the next pulse as a reaction on the pulse:
NewPulseTime = micros();
You react LATER in the loop than the pulse actually occurs.
Your timing is not actually based on the time when the pulses occur, but on the time when the reaction on the pulses occur in your program.
At only 10 Hz, this doesn't make a big difference and will be very, very close to 10 Hz.
At higher Frequencies that might become a problem.
As you don't show complete programs, it's impossible to find out about all the mistakes that may lead to inaccuracy.
One millisecond inaccuracy? OMG!
The pseudo code logic I posted above was of no worth for you?
I never said that my code was complete, I said, this is the part of the code that receives the pulse and outputs a frequency. It works FLAWLESS...
I'm not really sure why you dont think so? Perhaps you should have a second look at the interrupt code I posted above. (and my comments on the next post after the code I posted...)
I decided to use timing as THIS PULSE and TIME TO NEXT PULSE, instead of THIS PULSE and LAST PULSE as you suggest in your pseudo code previously. I did this since others (in other threads about timing) suggested that Time to next is a better way compared to Time since last, but essentially they are the same.
In terms of getting the input, I use interrupt to catch ANY frequency, simply counting microseconds between each received interrupt. I do probably get a little drift between pulses, and that might result in a bit of jitter. I'm gonna insert an "if" test to determine if the input frequency has changed more than 1% since last pulse, and if not, then choose not to update my incoming frequency, that should completely remove the jitter.
So for now, my code is simple:
Trigger on interrupt, save time.
Trigger on interrupt again (new pulse)
Calculate time difference, output frequency to loop
process frequency from loop
compare with current frequency (10% test + changes etc)
Calculate changes, based on input pins, real world switches (for now anyway for hardware testing)
Output frequency based on above code.
My current process is good. I need to implement some failsafe for external hardware, should I loose pulse input for one reason or another. Maybe a timer running, that defaults to a low "safe" frequency if no pulses are received for several seconds or something. I also need to revisit inputs once everything is tested.
I found that with the current code, I can output solid frequencies when input frequency stops, hence that's why I will implement the 1% or 10% test before changes made.