You got me interested in this Rob.
So, as I found my Neo-7 GPS board today, I though I'd try to learn a bit about how they work.
Good stuff Denys
As I pointed out in one other of my posts the use of the Neo programmable divider for a final output frequency is not a good idea as the output will have jitter (Something I worked very hard to mitigate in my design) This jitter is the consequence of the internal oscillator frequency of 48 MHz.
Here is a quote from a post in eevblog.com (
https://www.eevblog.com/forum/metrology/neo-7m-output-frequency-issue/)
Quote
"
As there are people using the cheapo ebay NEO-7M modules for generating 0.25Hz-10MHz frequencies (off the 1pps pin) here are some measurements how the Period of the output signal looks like.
Measurements done with a diy system, still some measurement jitter inside (<100ps rms), subject to an improvement..
The measurement confirms some concerns on a "large jitter" with 10MHz freq people try to use as a cheapo standard.
Based on my current understanding the frequencies which are not 48MHz/integer are a "nogo".
PS: The vertical scale is the sample's "period in picoseconds", the horizontal is the sample number.
Around 1000 samples/sec." End Quote
Trust me if I could have found a simpler method to achieve what I did I would have used it already.
The other point I make is that to asses the measure of stability and drift along with jitter one has to have instrument that have a resolution 10 times better than the final target measure.
Note that the instrument I have designed has a stability better that 3 PPB (+/- 1.5PPB) with ultra low jitter bordering Allan Noise
Concluding if you seek a signal that has a degree of known error and this is acceptable for the intended application then what you are doing is fine.
All other designs that use the Ublox GPS module mitigate the issues I pointed out either in using an ovenised or Temperature compensated Oscillator producing the final frequency, some do it better than others as the Trimble system ( In my opinion the best) that compensates for man introduced errors or path errors.
In your sketch I note you are using "#include <SoftwareSerial.h>" This library is buggy, causes stack overflow and corrupts the code causing a lock up, I spent a lot of time in locating what was causing my code to crash, use this library instead "#include <AltSoftSerial.h>"
You will need to install it into your libraries of the IDE
There is more to this than seen at first.