Ah okay. Because I found that the default start order of gpsmon and chrony was incorrect meaning that the shared memory communications wasn't working but there were no error messages stating this. So sometimes, it would sync (slowly) and then chrony sources would say that it was having microsecond sync time but when I connected a switch (On/Off type) to the same gpio on two separate Pi's with linked earth connections and had a python program output the system time in nano seconds I found that despite telling you it was keeping time accurate to microseconds it was in fact many milliseconds out. The only thing I can conclude is that despite the setup indicating that it should use the PPS source that use the interrupt, this was in fact not happening and it was somehow getting it's time from the serial line only. Without indicating that this was happening.
When I switched the startup of gpsmon and the chrony daemon to the other way around time sync was achieved within 1/2 minute to a minute (Real fast) and the reported time on two separate Pi's with the joined up gpio's (So you can get very close to triggering a time check at the same time) was then sometimes as low as 30 ns's from each other, which is damn good considering that most of the difference would be jitter.
And none of the how-to's that I read talked about changing the start order of chronyd and gpsmon so I can only assume they all might be suffering from the same problem. It's important to note that the diagnostic commands from chrony will not indicate this and the only way you will notice if this is happening if you setup a rig like I mentioned above. I noticed because my sound localization calculations were showing errors that didn't make sense.
I must admit I've never used chrony, so I'm unfamiliar with how to configure it. I've read a lot say saying gpsmon's shared-memory-segment is a really great interface and to go with it instead of NTP's own GPS drivers, but I cannot say that lines up with my experience. I do have one computer setup this way, and it works, but I found on the PPS configurations, it seemed to me to have better accuracy and less jitter using NTP's own GPS drivers and taking gpsmon out of the equation. Its quite possible I just don't know the right configuration combination, but ntpsec's own GPS drivers work great for me.
This is off-topic, but I was looking at your sbts-aru project and remembered having read the hackaday post on it about fireworks. I'm curious if you've ever seen the RaspberryShake BOOM sensor? If so, any thoughts on how your project and it differ?
I hadn’t seen that. It uses a pi so in principle it could sync the time the same way. How well related to localizable recordings would also depend on how it establishes the actual time arrival with the clock and how it deals with jitter.
Currently I only support USB mics at 16 bits that can talk to jackd. This was a conscious decision because it was all that was needed but also because jacks makes it essentially have multiple source sinks. Such as as well as recording a real time audio processing pipeline that potentially leads to real time gunshot and other sound event localization.
But it would be cool if the infrasound sensor had a USB sound interface. As then it could be useful in localizing elephants.
If it syncs time accurately by any method maybe you are able to localize some very interesting events! The localization code I provide with my project should fine with times obtained from this project. I seriously doubt whether that project uses a memory overlayFS but it’s to add as an improvement.
When I switched the startup of gpsmon and the chrony daemon to the other way around time sync was achieved within 1/2 minute to a minute (Real fast) and the reported time on two separate Pi's with the joined up gpio's (So you can get very close to triggering a time check at the same time) was then sometimes as low as 30 ns's from each other, which is damn good considering that most of the difference would be jitter.
And none of the how-to's that I read talked about changing the start order of chronyd and gpsmon so I can only assume they all might be suffering from the same problem. It's important to note that the diagnostic commands from chrony will not indicate this and the only way you will notice if this is happening if you setup a rig like I mentioned above. I noticed because my sound localization calculations were showing errors that didn't make sense.