Ok... What part of The raceiver needs to be designed to decode CQPSK are you not understanding. The problem with the scanner has NOTHING, ZIP, ZILCH, NADA to do with timing. It has to do with piss poor receiver design that uses an inferior discrimitor tap and not being an proper I/Q receiver...
I think I fully understand, this is why I stated/asked the question as to who is going to develop the retrofit/mod that will clean up the issue. There have been plenty of enterprising people that have developed/published mods to add features and/or improve the performance of devices, so for all the "experts" that fully understand what the issues is/are, how about a challenge to build a better mouse trap?
Also seems that plenty of people are wholesale discounting that there may not be some realistic things that could easily be done to maybe not 100% resolve things but significantly improve the situation with garbled audio.
Something like a more stable base clock source for the scanner might actually improve things by say 50%?? It might be worth it to some people. You can say all day long the demod is junk, wrong, poorly designed, poorly implemented, but you are also 100% discounting that a more stable clock source will offer NO improvement to stability and/or performance. I see the world this way, things become additive. So for example a questionable receiver and a poor base clock add up to degrade performance. When you start to stabilize and clean things up, you may see some incremental improvements. Maybe not resolve the issues 100%, but even a 10-20% improvement may be worth it to some people?
What I find very interesting is I can be listening to a longer dispatch that starts out perfectly clear and then starts to degrade as the dispatch goes on. I also have some comms that seems to be garbled from the beginning.
So more data will be needed to determine if the problem is adjacent channel interference, multipath, or issues only with specific frequencies and so forth. Each Public Safety system has its own set of issue and until data is gathered and people experiment, we may never know if there is any simple improvement that can be implemented.
So I think all the OP is trying to do here is gather data and see if there are any common factors and/or solutions other than spending close to $1k on a specific Motorola P25 radio configured to the system you want to monitor.
I have been in the communication industry to MANY years and I have found all sorts of problems that were discounted and overlooked by the "high level" engineer types and they become very humble when you can prove to them that something simple was causing all sorts of headaches.
I developed some very simple and unique ways of monitoring satellite communication signal paths. I was given a bunch of crap about them by all the "Engineers" until my tools were actually found to be accurate and reliable in finding issues. They were low cost, rather simple tools with Commercial Off The Self gear along with monitoring router interface error statics and I found all sorts of issues both in the ground stations and also with terrestrial interference that the "Engineers" could not find/solve and claimed were not present using their $100k spectrum analyzers, BER test sets and link budget analysis tools.
Then once everyone realized my tools were not a joke, I became the go to guy to help resolve all customer issues that "Engineering" was unable to resolve or claimed did not exist. Then my tools became one of the mainstream daily tool sets that was even used by end customers.
So again, I do not think anyone is looking for a 100% solution, they are just gathering data and letting the data speak for itself to show and determine if there can be ANY improvement to garbled audio in the P25 systems.