RadioReference on Facebook   RadioReference on Twitter   RadioReference Blog
 

Go Back   The RadioReference.com Forums > Scanners and Receivers Forums > Uniden Forums > Uniden Advanced Technical Topics

Uniden Advanced Technical Topics For all threads regarding technical performance of specific models or general higher tier, technically oriented discussion of the technology used in Uniden scanners. Please use the Tech Support forum for all normal questions.

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old 03-03-2014, 4:44 PM
Member
  Premium Subscriber
Premium Subscriber
Amateur Radio Operator
Amateur Radio
 
Join Date: May 2007
Location: DFW Texas
Posts: 279
Default Uniden P25 Simlucast - Possible Solution to Ponder

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
__________________
ICOM HF R71A ~ Pro-400 ~ IC R10 ~ Pro 2052 ~ Pro 2055 ~ Pro 92 ~ Kenwood TH F6a - Yeasu FTM-350 - Home Patrol - FunCube - WinRadio ~ PRC 1500 ~ Ventenna ~ J-Poles ~ Alfa Delta HF DD -Milair - SATCOM
Reply With Quote
Sponsored links
  #2 (permalink)  
Old 03-03-2014, 4:56 PM
whsbuss's Avatar
Member
   
Join Date: Jun 2005
Location: SE Pa
Posts: 483
Default

Quote:
Originally Posted by Alliance01TX View Post
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?
Reply With Quote
  #3 (permalink)  
Old 03-03-2014, 6:28 PM
Member
  Premium Subscriber
Premium Subscriber
Amateur Radio Operator
Amateur Radio
 
Join Date: May 2007
Location: DFW Texas
Posts: 279
Default 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
__________________
ICOM HF R71A ~ Pro-400 ~ IC R10 ~ Pro 2052 ~ Pro 2055 ~ Pro 92 ~ Kenwood TH F6a - Yeasu FTM-350 - Home Patrol - FunCube - WinRadio ~ PRC 1500 ~ Ventenna ~ J-Poles ~ Alfa Delta HF DD -Milair - SATCOM
Reply With Quote
  #4 (permalink)  
Old 03-03-2014, 7:07 PM
Member
   
Join Date: Jan 2003
Location: McLean, VA
Posts: 1,110
Default

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.
__________________
AOR AR5000+3 & SDU, AR8000, Icom R71A, R7100, PRO2004, PRO2006, PRO43, PRO96, PRO2096, BC785D, HP1E, 396XT, 996XT, 436HP, 536HP. Probably missed some gear. Man, I gotta get rid of some of this stuff!
Reply With Quote
  #5 (permalink)  
Old 03-03-2014, 7:25 PM
Member
   
Join Date: Apr 2011
Posts: 63
Default

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
Reply With Quote
Sponsored links
  #6 (permalink)  
Old 03-03-2014, 8:24 PM
Mike_G_D's Avatar
Member
   
Join Date: Dec 2002
Location: Carlsbad, CA
Posts: 853
Default

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
Reply With Quote
  #7 (permalink)  
Old 03-04-2014, 8:04 AM
Member
  Premium Subscriber
Premium Subscriber
Amateur Radio Operator
Amateur Radio
 
Join Date: May 2007
Location: DFW Texas
Posts: 279
Default

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'...
__________________
ICOM HF R71A ~ Pro-400 ~ IC R10 ~ Pro 2052 ~ Pro 2055 ~ Pro 92 ~ Kenwood TH F6a - Yeasu FTM-350 - Home Patrol - FunCube - WinRadio ~ PRC 1500 ~ Ventenna ~ J-Poles ~ Alfa Delta HF DD -Milair - SATCOM
Reply With Quote
  #8 (permalink)  
Old 03-04-2014, 8:24 AM
whsbuss's Avatar
Member
   
Join Date: Jun 2005
Location: SE Pa
Posts: 483
Default

Quote:
Originally Posted by Alliance01TX View Post
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.
Reply With Quote
  #9 (permalink)  
Old 03-04-2014, 4:48 PM
Member
  Premium Subscriber
Premium Subscriber
Amateur Radio Operator
Amateur Radio
 
Join Date: May 2007
Location: DFW Texas
Posts: 279
Default 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!
__________________
ICOM HF R71A ~ Pro-400 ~ IC R10 ~ Pro 2052 ~ Pro 2055 ~ Pro 92 ~ Kenwood TH F6a - Yeasu FTM-350 - Home Patrol - FunCube - WinRadio ~ PRC 1500 ~ Ventenna ~ J-Poles ~ Alfa Delta HF DD -Milair - SATCOM
Reply With Quote
Sponsored links
  #10 (permalink)  
Old 03-05-2014, 7:49 PM
Member
  Premium Subscriber
Premium Subscriber
Amateur Radio Operator
Amateur Radio
 
Join Date: May 2007
Location: DFW Texas
Posts: 279
Default

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
__________________
ICOM HF R71A ~ Pro-400 ~ IC R10 ~ Pro 2052 ~ Pro 2055 ~ Pro 92 ~ Kenwood TH F6a - Yeasu FTM-350 - Home Patrol - FunCube - WinRadio ~ PRC 1500 ~ Ventenna ~ J-Poles ~ Alfa Delta HF DD -Milair - SATCOM
Reply With Quote
  #11 (permalink)  
Old 03-05-2014, 9:21 PM
Member
   
Join Date: Sep 2008
Location: In the 'patch
Posts: 2,237
Default

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.
__________________
Interoperatablity is not a technology it is an attitude!!!
Reply With Quote
  #12 (permalink)  
Old 03-06-2014, 5:28 PM
Member
  Premium Subscriber
Premium Subscriber
Amateur Radio Operator
Amateur Radio
 
Join Date: May 2007
Location: DFW Texas
Posts: 279
Default

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...
__________________
ICOM HF R71A ~ Pro-400 ~ IC R10 ~ Pro 2052 ~ Pro 2055 ~ Pro 92 ~ Kenwood TH F6a - Yeasu FTM-350 - Home Patrol - FunCube - WinRadio ~ PRC 1500 ~ Ventenna ~ J-Poles ~ Alfa Delta HF DD -Milair - SATCOM
Reply With Quote
  #13 (permalink)  
Old 03-06-2014, 5:42 PM
MikeOxlong's Avatar
Global DB Admin/Senior Mod
  RadioReference Database Admininstrator
Database Admin
 
Join Date: Jun 2001
Location: Central Ontario
Posts: 6,367
Default Uniden P25 Simlucast - Possible Solution to Ponder

Quote:
Originally Posted by kayn1n32008 View Post
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.
__________________
Mike.

Sorry but I don't accept PM's. Please use email instead.
Reply With Quote
  #14 (permalink)  
Old 03-06-2014, 5:49 PM
Member
   
Join Date: Jan 2003
Location: McLean, VA
Posts: 1,110
Default

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.
__________________
AOR AR5000+3 & SDU, AR8000, Icom R71A, R7100, PRO2004, PRO2006, PRO43, PRO96, PRO2096, BC785D, HP1E, 396XT, 996XT, 436HP, 536HP. Probably missed some gear. Man, I gotta get rid of some of this stuff!
Reply With Quote
  #15 (permalink)  
Old 03-06-2014, 8:48 PM
Member
   
Join Date: Sep 2008
Location: In the 'patch
Posts: 2,237
Default

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+)

Quote:
Originally Posted by JamesO
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...
__________________
Interoperatablity is not a technology it is an attitude!!!
Reply With Quote
Sponsored links
  #16 (permalink)  
Old 03-06-2014, 9:16 PM
Member
  Premium Subscriber
Premium Subscriber
Amateur Radio Operator
Amateur Radio
 
Join Date: May 2007
Location: DFW Texas
Posts: 279
Default

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.
__________________
ICOM HF R71A ~ Pro-400 ~ IC R10 ~ Pro 2052 ~ Pro 2055 ~ Pro 92 ~ Kenwood TH F6a - Yeasu FTM-350 - Home Patrol - FunCube - WinRadio ~ PRC 1500 ~ Ventenna ~ J-Poles ~ Alfa Delta HF DD -Milair - SATCOM
Reply With Quote
  #17 (permalink)  
Old 03-06-2014, 9:49 PM
jcardani's Avatar
Member
  Audio Feed Provider
Audio Feed Provider
Amateur Radio Operator
Amateur Radio
 
Join Date: Jan 2002
Location: Voorhees, NJ
Posts: 734
Default

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.

Quote:
Originally Posted by JamesO View Post
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.
__________________
Joe Cardani, KC2TUS
Editor, Philadelphia Area Communications Guide/Metro Master Guides
Owner, PhillyScanner Yahoo Group
Live Audio http://www.phillyscanner.com/live.html

Last edited by jcardani; 03-06-2014 at 9:53 PM..
Reply With Quote
  #18 (permalink)  
Old 03-07-2014, 7:11 AM
Member
   
Join Date: Jan 2003
Location: McLean, VA
Posts: 1,110
Default

Quote:
Originally Posted by kayn1n32008 View Post
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.
__________________
AOR AR5000+3 & SDU, AR8000, Icom R71A, R7100, PRO2004, PRO2006, PRO43, PRO96, PRO2096, BC785D, HP1E, 396XT, 996XT, 436HP, 536HP. Probably missed some gear. Man, I gotta get rid of some of this stuff!
Reply With Quote
  #19 (permalink)  
Old 03-07-2014, 8:48 AM
Member
  Premium Subscriber
Premium Subscriber
Amateur Radio Operator
Amateur Radio
 
Join Date: May 2007
Location: DFW Texas
Posts: 279
Default 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
__________________
ICOM HF R71A ~ Pro-400 ~ IC R10 ~ Pro 2052 ~ Pro 2055 ~ Pro 92 ~ Kenwood TH F6a - Yeasu FTM-350 - Home Patrol - FunCube - WinRadio ~ PRC 1500 ~ Ventenna ~ J-Poles ~ Alfa Delta HF DD -Milair - SATCOM
Reply With Quote
  #20 (permalink)  
Old 03-07-2014, 11:22 PM
Member
   
Join Date: Sep 2002
Location: Toronto, Ontario
Posts: 2,325
Default

Quote:
Originally Posted by JamesO View Post
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.
Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT -5. The time now is 2:42 AM.


Powered by vBulletin® Version 3.8.2
Copyright ©2000 - 2014, vBulletin Solutions, Inc.
All information here is Copyright 2012 by RadioReference.com LLC and Lindsay C. Blanton III.Ad Management by RedTyger
Copyright 2011 by RadioReference.com LLC Privacy Policy  |  Terms and Conditions