Uniden P25 Simlucast - Possible Solution to Ponder

Status
Not open for further replies.

Alliance01TX

Member
Premium Subscriber
Joined
May 11, 2007
Messages
371
Location
DFW Texas
Uniden might concider the following as one posible solution for P25 Simlucast solutions via hardware/software engineering and design reviews on the active use of the GPS cabability and related GPS clocking at most reasonable Stratum Level.

P25 Simo requires a heavy use of sync timing via GPS.

Thus, if the Uniden Products can, perhaps, better harvest GPS timing (GPS data streams) this might be one of several solutionns in improvements in simo reception decoding.

This is not a fix all solution, but as GPS is at the heart of P25/Simo system one should look at this deeper as a possible solution set. Perhaps this was overlooked in the design as most scanners were built on a single system thought process and as simo becomes more of a reality, especially the new State-Wide systems this will be a likely high-priority item to solution

Just a point for Uniden (UpMan) and the team to look into as GPS is a part of the new scanners - perhaps a second look at how the GPS is (or is-not) used within the scanner would be interesting...

Bill
 

whsbuss

Member
Joined
Jun 15, 2005
Messages
547
Location
SE Pa
Uniden might concider the following as one posible solution for P25 Simlucast solutions via hardware/software engineering and design reviews on the active use of the GPS cabability and related GPS clocking at most reasonable Stratum Level.

P25 Simo requires a heavy use of sync timing via GPS.

Thus, if the Uniden Products can, perhaps, better harvest GPS timing (GPS data streams) this might be one of several solutionns in improvements in simo reception decoding.

This is not a fix all solution, but as GPS is at the heart of P25/Simo system one should look at this deeper as a possible solution set. Perhaps this was overlooked in the design as most scanners were built on a single system thought process and as simo becomes more of a reality, especially the new State-Wide systems this will be a likely high-priority item to solution

Just a point for Uniden (UpMan) and the team to look into as GPS is a part of the new scanners - perhaps a second look at how the GPS is (or is-not) used within the scanner would be interesting...

Bill

I'm not sure how GPS would affect a listener at a fixed location. For example, I have 5 simulcast towers within 5 miles of my location. One is less than 1 mile but at a higher elevation. How would GPS allow the radio to only receive the best signal when they are on the same freq. at the same time?
 

Alliance01TX

Member
Premium Subscriber
Joined
May 11, 2007
Messages
371
Location
DFW Texas
Uniden P25 Simlucast

The point of investigation centers around "timimg and sync" that GPS or a land-line capabilitiy can provide to keep the systems "in sync" for various reasons.

Not about using GPS as a location based as currently used, rather the GPS timing pluses derived that are in use by a P25 Simlucasting system and thus the internal scanner would be using the same level ( or close as reasonable based on cost ) as possible.

Hence, the scanner reception would / could perhaps better decode the CC/Voice channels and improve reception in simlucast.

This is an area to investigate and may be costly as if the GPS hardware/software in a device is only capabile of a wide degree of tolerance then the delta would likely result in higher Bit Error Rates, which translates into reception issues often manafesting into dropped bits / decoding issues and in audio garbled or totally missed reception depending on the units error control and recovery capabilities, etc...

Investigation might be in order...

Bill
 

JamesO

Member
Joined
Jan 22, 2003
Messages
1,814
Location
McLean, VA
I have been pondering this to some extent myself.

I was considering using an external higher performing OCXO clock oscillator to see what may happen with the Voice Demodulation and stability.

External GPS timing might be a good low cost option for the units, using a clock recovery loop and exteranl timing reference from the GPS unit even in a stationary environment.

I had read somewhere as well that some digital systems may sync remote unit timing to the control channel and/or the receive signal. It was a long time ago I read about this system so I do not recall if it was P25 or some other system.

Clock slips and jitter can cause a lot of problems with decoding and the more stable the base clocks are the more reliable the decoding of the voice traffic. Also the base clock controls the receive synthesizer so between a combination of receiver instability/drift/wander along with the decoding circuitry instability/drift/wander these can add up.

I know many land mobile systems and cell systems use a master timing source with an external GPS antenna to stabilize the external timing source to an even greater degree.

When I have some spare time I need to start with one of my 996XT and put a timing loop from the master oscillator so I can use a higher quality external reference.
 

Roveer

Member
Joined
Apr 29, 2011
Messages
196
For fixed stations such as mine. If location had something to do with timing and the decode couldn't th concept of a variable clocking timer be used to tune your fixed location? I'm way ahead of my knowledge of electronics here but it seems like I'm always looking for the knob I used to use for SSB. Don't gt me wrong. I understand we are digital but I'm looking at this from 35k feet.

Roveer
 

Mike_G_D

Member
Joined
Dec 19, 2002
Messages
1,241
Location
Vista, CA
I think that there might be some confusion here regarding how simulcast systems use precision timing. The fixed transmit sites (the site transmitters involved in a simulcast system) use precision timing based on a common signal (via dedicated lines, microwave links, etc.) so that multiple sites attempt to keep their transmissions in phase with each other while transmitting. During initial setup and in later periodic maintenance, adjustments in timing may need to be made for specific sites due to changing environmental conditions and/or local multipath channel changes in order to keep the collective phase distortion within the required coverage area inside acceptable limits.

That is for the fixed transmission sites; the user subscriber units do not (at least routinely, as far as I know) use that external precision timing signal. I'm talking about a completely separate timing signal distinct from the control channel and voice channel references. Of course, the user receivers will have high quality TCXO's and/or VCTCXO's on board that may also use the output of the site transmitters to "steer" their local oscillator references back on the right track (at least relative to the transmissions from the sites they are receiving) frequency-wise but this will likely not correct for phase distortion (beyond that which is incurred from receive frequency drift error).

True, having improved local oscillator references can't hurt and would help but transmission phase issues within a simulcast coverage area are more of a relative timing delta condition between involved sites than an absolute frequency accuracy condition localized at the user's receiver.

Then there is the practical considerations of relying on a local GPS receiver to keep the communications receiver's local on-board references accurate. In theory, this could work, for frequency accuracy though not necessarily for phase accuracy, but needing to have a reliable on-board GPS receiver in portable environments might be practically problematic - using one as your local oscillator reference base is a bit different from using one in a cell phone for location tracking. In my mind, whether portable or mobile, having the ability to allow a basic non-technical user to get periodic maintenance "retunes" from an external reference or using a known good (relatively speaking) local transmission (say, from a system control channel) might indeed be a good way to keep the equipment within spec frequency accuracy-wise over a longer period of usage without having to be worked on in the traditional sense (opened up on the bench) and could be done, I think, with current hardware and software technology. But this would not ultimately "solve" simulcast issues by itself.

I still believe the primary focus for proper receiver handling of digital simulcast transmissions (as well as other forms of complex digital modes with more complicated constellation representations) revolves around correct handling of the I and Q demodulation, whether in hardware or DSP software form; until that is properly addressed in consumer scanning equipment any other solution or set of solutions will likely be incomplete at best.

-Mike
 

Alliance01TX

Member
Premium Subscriber
Joined
May 11, 2007
Messages
371
Location
DFW Texas
Mike and Team

Excellent points and information.

You are correct this is (as noted) not "the" solution and might just be one of several areas to investigate and ponder. As you said, the decode is a key-stone issue as is tight filtering, and likely more important if the location is dense with RF as most metro areas are, including RFI issues with new technologies, etc..

I feel a combined set of solutions are called for by the Scanner folks and a lot more Technical Field Testing that provides Technical Data as Beta Test via selected users is still valid but should not take the place of solid Engineering & Testing in the Field...

We have all seen the results of "well boss it looked good on the Lab Bench in a perfect, climate-controlled room with no RFI/EMI and the paperwork indicates it shouldn't be an issue..."

So lots of possible and collective Solutions awaiting and perhaps then "next one" will be less about 'Form over Function'...
 

whsbuss

Member
Joined
Jun 15, 2005
Messages
547
Location
SE Pa
Mike and Team

Excellent points and information.

You are correct this is (as noted) not "the" solution and might just be one of several areas to investigate and ponder. As you said, the decode is a key-stone issue as is tight filtering, and likely more important if the location is dense with RF as most metro areas are, including RFI issues with new technologies, etc..

I feel a combined set of solutions are called for by the Scanner folks and a lot more Technical Field Testing that provides Technical Data as Beta Test via selected users is still valid but should not take the place of solid Engineering & Testing in the Field...

We have all seen the results of "well boss it looked good on the Lab Bench in a perfect, climate-controlled room with no RFI/EMI and the paperwork indicates it shouldn't be an issue..."

So lots of possible and collective Solutions awaiting and perhaps then "next one" will be less about 'Form over Function'...

Good comments. But I'm not sure if ANY manufacturer will want to invest time and $$$ to develop a "true" solution. First, scanners are marketed as wide-range devices that can do ALL in receiving a diverse universe of systems, frequencies. Digital, analog, trunked systems, P25, etc. makes engineering a reliable device almost impossible. Their claim to fame is "hear exciting events as they occur no matter where you travel.

Whereas commercial manufacturers engineer device for specific uses. I doubt Motorola or Harris claims their units work in NYC and LA by just traveling there. Scanner manufacturers would find it hard to create specific radios for just digital, P25 or analog alone.

Second, as many are now seeing with new system deployments, agencies are opting for encrypted operation. This is especially true for police, swat, detectives, etc. to reduce outside exposure. So when we are left with listening to just road crews and local gov't stuff, I'm not sure scanner manufacturers will be so willing to innovate.
 

Alliance01TX

Member
Premium Subscriber
Joined
May 11, 2007
Messages
371
Location
DFW Texas
P25 Simo

Agree and all valid points in general and with the P25 at least the InterOp is one plus out of most of the minus sides.

And suspect as the mandated Digital / P25 continues this will be a hard-fact to look at by any possible new scanner compaines - if we ever have any more now that GRE is gone....perhaps they really did see the writing on the wall - perhaps other debatable reasons - doesn't matter I suspose as the end outcome was they are historiy and unless the much spectulated return, via Whistler happens i would doubt any serious scanner competitors are forthcomming - yet Kenwood and ICOM could see a possible secondary market via even a refurb (transmiter disabled) market perhaps?

Meanwhile we tinker with trying to make a Fox hunt the Dog...

I wonder if folks would rush to buy a new $40.k car (after "extensive" beta testing..) and only then discover or understand all the dials were in a non-ergo config and then find the wipers only work during a snow storm - P.T. Barum was right!
 

Alliance01TX

Member
Premium Subscriber
Joined
May 11, 2007
Messages
371
Location
DFW Texas
Team

Here is a one example of a GPS Chip (< $50.) that someone much smarter and perhaps with a IEEE Degree ( not a "BS" degree...) might. ponder to intergrate / test to perhaps improve several issues in P25 / Simlucast..

AD9548 datasheet and product info | Quad/Octal Input Network Clock Generator/Synchronizer | Clock Generation and Distribution | Analog Devices

Again, this a just a concept based on other uses and is not the solution, but a possible one in many that might generate serious Enginerring Design for the next generation scanner...

Bill
 

kayn1n32008

ØÆSØ
Joined
Sep 20, 2008
Messages
6,601
Location
Sector 001
Wirelessly posted (Mozilla/5.0 (BlackBerry; U; BlackBerry 9900; en-US) AppleWebKit/534.11+ (KHTML, like Gecko) Version/7.1.0.1047 Mobile Safari/534.11+)

The problem with uniden radios inability to properly decode silmulcast systems has all to do with poor receiver design. Having an external timing reference can not fix the issue with having a receiver designed to decode 4FSK, and trying to apply that method to decode CQPSK... Does not work.

I'm trying to figure out how a external timing reference can help fix poor decode by a receiver that is completly passively monitoring a radio system that has already phase sync'd all of its transmitter.

The problem with Uniden receivers is that they are NOT designed to properly decode CQPSK... With out going to a PORPERLY designed I/Q receiver, no firmware updates will ever fix the issue.

Kinda like why the 396xt can not be 'upgraded' to decode TDMA systems, the hardware does not support it. The X36 recievers are not designed to decode CQPSK.

C4FM yes, CQPSK nope.
 

Alliance01TX

Member
Premium Subscriber
Joined
May 11, 2007
Messages
371
Location
DFW Texas
Vaild points on the long-standing Decode discussion - just looking a what-if on the Timing aspects internal to the Radio and if the inclusion of 'same-source-timing" (GPS Timing Pluses) would help or hinder...?

Seems in the once-upon a time in Telecom if you have two separate Timing References that, in general it was not a good idea...thus, wonder if the Next Gen Scanner (with perhaps proper Decoder as noted) would benefit from the inclusion of a simple $25 chip...

Retrofitting would likely not be an option I suspect.

I don't know and won't pretend to know as not my area of expertise in hardware / software design....but sounds like something to ponder...maybe impossible...
 

mikewazowski

Forums Manager/Global DB Admin
Staff member
Forums Manager
Joined
Jun 26, 2001
Messages
13,459
Location
Oot and Aboot
I'm trying to figure out how a external timing reference can help fix poor decode by a receiver that is completly passively monitoring a radio system that has already phase sync'd all of its transmitter.


As has already been explained above, it can't.
 

JamesO

Member
Joined
Jan 22, 2003
Messages
1,814
Location
McLean, VA
So who is going to develop the retrofit board that will solve this???

Seems that for at least the base/mobile scanners a retrofit could be put together?

I think a number could be sold if it really solved the problem and was less than $150.
 

kayn1n32008

ØÆSØ
Joined
Sep 20, 2008
Messages
6,601
Location
Sector 001
Wirelessly posted (Mozilla/5.0 (BlackBerry; U; BlackBerry 9900; en-US) AppleWebKit/534.11+ (KHTML, like Gecko) Version/7.1.0.1047 Mobile Safari/534.11+)

JamesO said:
So who is going to develop the retrofit board that will solve this???

Seems that for at least the base/mobile scanners a retrofit could be put together?

I think a number could be sold if it really solved the problem and was less than $150.

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...
 

Alliance01TX

Member
Premium Subscriber
Joined
May 11, 2007
Messages
371
Location
DFW Texas
Will Close this thread shortly as apparently it has been determined this is not possible / feasible and no improvements can be derived from same - Thanks for the help.
 

jcardani

Member
Premium Subscriber
Joined
Jan 16, 2002
Messages
1,390
Location
Orlando, FL & Ocean City, NJ
First kayn1n32008 is correct with why GPS is not the solution. The correct solution is proper circuitry and demodulation of CQPSK signals.

A retrofit board certainly can be developed, I actually was thinking how it can be done for a few weeks now.
This can be done in a DSP chip or dedicated communications chips (from CML Microcircuits).
You would need to tap the scanner's 450 or 455 KHz IF (depending on scanner manufacturer) down convert that to 24 KHz, demodulate to I and Q , perform A/D then input the signals to the DSP chip. I Q demodulation can also be done in the DSP simplifying hardware. Then The DSP would need to perform clock recovery using a costs loop, then bit recovery using the gardner algorithm. This performs the CQPSK demodulation. The raw decoded bits would be put into a buffer then get sent to a second DSP to be re-modulated using C4FM. Then the signal gets D/A and then mixed back to 450/455 Khz and finally back to the scanner's IF. Obviously this circuit would need to be switchable. A member of this board already created a gardner-costas loop method for the OP-25 project (under GNURadio), and it works great for LSM systems.

I would love to get started on this project but I would need lots of help from those on the list that understand signal processing and coding better than me. I have developed a Passport decoder using a PIC micro controller and software written in C but this is much more complicated. But I can think of at least 5-10 RR members that's qualified to assist.

So who is going to develop the retrofit board that will solve this???

Seems that for at least the base/mobile scanners a retrofit could be put together?

I think a number could be sold if it really solved the problem and was less than $150.
 
Last edited:

JamesO

Member
Joined
Jan 22, 2003
Messages
1,814
Location
McLean, VA
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.
 

Alliance01TX

Member
Premium Subscriber
Joined
May 11, 2007
Messages
371
Location
DFW Texas
What If....

Gents

Great discussion and out-of-the-box thinking here and appreciated as clearly New Gen Scanners (be it a like line as we have had, or perhaps a Hybrid SDR, etc...) might benefit as we give us some amount of "what-if" going forward as noted in most post above....

We do have the 'nay-sayers' in abundance at times and lots of "noise" from the "side-liners" as well, as expected.

So I would would guess if you were to Prototype something & if made a reasonable improvement (not saying it was perfect) I suspect the same folks would be cutting in line to be the first to ask and own one...

So again thanks and if an existing SDR and-or New Scanner maker was to look at your ideas it just might benefit the hobby..

Thx

Bill
 

slicerwizard

Member
Joined
Sep 19, 2002
Messages
7,643
Location
Toronto, Ontario
Something like a more stable base clock source for the scanner might actually improve things by say 50%??
So Unidens have reference clocks that are so jittery and/or off-frequency that they can't handle slow 4800 or 6000 baud symbol streams? And fixing the clock will yield a 50% improvement? This is what you're suggesting? Are you aware that software decoders (TRUNK88, UT, DSD+, ...) don't even have reference clocks? No offense, but you're sounding as far off base as the thread starter.
 
Status
Not open for further replies.
Top