improving 500s digital

Status
Not open for further replies.

AZScanner

Member
Joined
Dec 19, 2002
Messages
3,342
Location
Somewhere in this room. Right now, you're very col
DonS said:
Simulcast is like multipath on steroids. Instead of multipath's several reflected (and therefore drastically attenuated) signals, you have multiple non-reflected, non-attenuated (except by distance) signals - all carrying the same data on the same frequency, but out-of-phase based on receiver distance from the various transmitters (and delays in transmitting among the transmitters, etc.). I imagine that the desired signal/data could be filtered or reconstructed, either electronically or algorithmically (e.g. in a DSP), but I doubt that many, if any at all, $500 consumer-grade scanners do such a thing.

I guess that's what the other $4500 in the price of the actual PD radios is for - DSP and/or error correction. LOTS of error correction... :D

Too bad there isn't (well maybe there is, I don't own a PSR so I don't know) a setting that would force the scanner to stay on a voice frequency once it's assigned until the signal drops to a point where it would close the squelch. It wouldn't completely solve the problem, but it would prevent the scanner from thinking the transmission ended before it actually did. Thus, if data errors temporarily stop decoding, hopefully the next error free packet would kick the decoder back into gear and you'd hear more of the transmission without having to resample the control channel first to find out "hey, go back, they're still talking over there!".

Just a thought... very interesting topic.

-AZ
 

DonS

Member
Joined
Jun 17, 2003
Messages
4,102
Location
Franktown, CO
AZScanner said:
Actually, not always. See this thread: http://www.radioreference.com/forums/showpost.php?p=796401&postcount=1

The PRWN (Phoenix Regional Wireless Network) is more affectionately known among us Phoenix area scanner hobbyists as the Radio System from Hell (and that's the nice term for it). Most of today's digital lineup does from fair to horrible on this system, even the new PSR radios. So, out of both necessity and frustration, one of the locals here did some experimenting and found that pointing a directional antenna AWAY from the closest site actually yielded better results than pointing it right at the tower.

In short, definitely get a directional antenna but experiment to see what direction to point the thing. You may find that the ideal spot is not at the nearest tower but between two others, or at one a bit farther away. Especially those of you reporting a full 5 bars of signal strength. In the digital world, too much signal can be just as bad as too little.
A little clarification of the above...

The AZ forum post referenced shows that the user aimed his directional antenna such that it was almost directly at the desired tower. The real goal, though, was to minimize reception from the interfering towers. Instead of pointing straight at the desired tower, the overriding goal of attenuating the other towers resulted in an approx. 6 degree deviation from the desired tower.
 

DonS

Member
Joined
Jun 17, 2003
Messages
4,102
Location
Franktown, CO
AZScanner said:
Too bad there isn't (well maybe there is, I don't own a PSR so I don't know) a setting that would force the scanner to stay on a voice frequency once it's assigned until the signal drops to a point where it would close the squelch. It wouldn't completely solve the problem, but it would prevent the scanner from thinking the transmission ended before it actually did. Thus, if data errors temporarily stop decoding, hopefully the next error free packet would kick the decoder back into gear and you'd hear more of the transmission without having to resample the control channel first to find out "hey, go back, they're still talking over there!".
I'm pretty sure the PSR actually works in the opposite manner. Once it starts receiving digital audio, RF squelch is secondary. Instead, it relies on good digital packets. If it stops receiving good digital packets for some time (no matter what RF squelch does), it presumes the transmission is over.

I think that's the "right" way to do it, since lack of good digital packets means no audio. The scanner may as well go back to the CC.
 

SCPD

QRT
Joined
Feb 24, 2001
Messages
0
Location
Virginia
DonS said:
Instead, it relies on good digital packets. If it stops receiving good digital packets for some time (no matter what RF squelch does), it presumes the transmission is over.
Under crappy conditions - you lose the frame sync and data unit id (the 4 bit packet type buried in the NID) which means you can't tell a voice frame from a terminating frame. I think there's some room here to combine the three inputs available to the radio - lack of carrier, continuous lack of frames, observation of frame types (eg. terminator vs. voice frame). The radio may do this already.
 

DonS

Member
Joined
Jun 17, 2003
Messages
4,102
Location
Franktown, CO
Unitrunker said:
Under crappy conditions - you lose the frame sync and data unit id (the 4 bit packet type buried in the NID) which means you can't tell a voice frame from a terminating frame. I think there's some room here to combine the three inputs available to the radio - lack of carrier, continuous lack of frames, observation of frame types (eg. terminator vs. voice frame). The radio may do this already.
I'm pretty sure the radio does only the latter two (lack of frames and checking for terminator).

In any case, "bad data" means "lack of frames", which satisfies one of the three conditions.
 

AZScanner

Member
Joined
Dec 19, 2002
Messages
3,342
Location
Somewhere in this room. Right now, you're very col
DonS said:
I'm pretty sure the PSR actually works in the opposite manner. Once it starts receiving digital audio, RF squelch is secondary. Instead, it relies on good digital packets. If it stops receiving good digital packets for some time (no matter what RF squelch does), it presumes the transmission is over.

I think that's the "right" way to do it, since lack of good digital packets means no audio. The scanner may as well go back to the CC.

Yep, I'll agree with you there - that's the "right" way to do it, but when you are monitoring these God-cursed simulcast systems you can lose "good" packets in a hurry.

If you're right (and you probably are - you're alot closer to the technical ins and outs of these things than me) then it all makes sense. The problem seems to be that the scanner isn't giving the DVSI vocoder enough benefit of the doubt. for example, if the scanner works like this:

>--rf signal-->--convert to packets-->---pass to vocoder--->---vocoder passes audio to speaker-->

and it encounters enough bad data, the scanner hops back to the CC, which will then tell it to go back to the voice channel, and the process repeats ad nauseum. When the scanner is parked on the voice frequency conventionally there is no "go back to the CC if the data turns to crap" and that's why my rusty old BC250D decodes better than my newer "P25 ready" 796D.

Therefore, my workaround would help. It could be a user defined setting; ON would mean that it behaves the "right" way you described (and should be the default setting) and OFF would mean "hold on to the voice channel until the signal drops below the squelch threshold" for systems like ours that, quite frankly, "didn't have Wookies in mind when they designed 'er, Chewie" :lol:. I could confirm the idea by writing a quick and dirty test program for my 796 which would essentially do the same thing. Think I'll try it just for funsies.

-AZ
 

DonS

Member
Joined
Jun 17, 2003
Messages
4,102
Location
Franktown, CO
AZScanner said:
for example, if the scanner works like this:

>--rf signal-->--convert to packets-->---pass to vocoder--->---vocoder passes audio to speaker-->

I'll bet it's more like:
>--rf signal-->--demodulate C4FM or CQPSK-->--find valid packets-->---pass valid packets to vocoder--->---vocoder passes audio to speaker-->

EDIT: in the case of simulcast-caused problems, it isn't a matter of "giving the DVSI vocoder enough benefit of the doubt". The problem is that you can't decode valid packets to give to the vocoder. It wants voice frames, and those have to be demodulated/detected first. It doesn't want a mere stream of demodulated bits from the RF.

I think you said above that you don't have a PSR-500. If you did, you could, perhaps, try tweaking the "Noise Thresh" and "DG Int Prime" items. Increasing them may help to minimize the periodic "dropouts" in digital voice under noisy conditions, though increasing the latter could also increase missed syllables at the beginning of "auto" analog transmissions.
 
Last edited:

Mike_G_D

Member
Joined
Dec 19, 2002
Messages
1,241
Location
Vista, CA
Simulcast mishmash

I find all this discussion about simulcast issues quite interesting. I used to work for a large company that was designing some of the first DAMPS cellular phones. We had a really brilliant individual who concentrated almost exclusively on what we called “the equalizer”. At the time, at first, I was a bit unclear what this beast was but I later got the gist of it (I think). My background is primarily RF hardware with some analog and digital hardware thrown in the mix, DSP algorithms are not my forte’, unfortunately. This “equalizer guy” was a DSP guru – all mathematics pretty much. And that was what the equalizer was – an algorithm with a very specific purpose. It was (as best my limited brain could comprehend) supposed to overcome the problems with decoding digitally modulated RF in heavy multipath situations. So, in a nutshell, (assuming I got this right – and I am sure I am oversimplifying) the equalizer was supposed to look at several simultaneously received identical but out of phase signals and sort it all out to get one nicely decoded data stream which was then passed on to the vocoder. It wasn’t the same as basic error correction in the sense that (beware, I am in my ignorance zone here) it didn’t just compensate for dropped or flipped bits; it actually looked at the data and tried to overcome specifically the problems associated with receiving multiple otherwise identical but with randomly or pseudo-randomly varying phase and amplitude components. From what I can remember the equalizer did this at the baseband level (not audio but at the IF after running through the I/Q demodulator and subsequent demodulation circuitry – the raw bits right after being extracted from the RF carrier which includes all of the parity, framing, etc. overhead) and I really can’t get my head around how that could be done (it’s bits, ok – how do you tell that they came from some out-of-phase mishmash at the RF level and how do you extract the “correct” pattern from same?) but, as I said, I am pretty much an idiot in this area.

Thinking back, now I wonder if maybe they were digitizing the downconverted IF, either before or after the I/Q demodulator, and running that through a dedicated DSP engine which ran algorithms on the digitized IF signal to detect and compensate for phasing issues and then converting the IF data back to (cleaned of multipath distortion) analog and then running it through the demodulation circuitry – I can sort of half see how that could be a possibility. But, for some reason, I am still thinking he did this using the raw bits that were finally extracted from the RF/IF carrier and, if so, it might as well be magic to me. And I do think that he had a dedicated DSP engine to handle all this either way.

My point here is that though cell phones didn’t deal so much with simulcast issues they did deal with some heavy multipath problems and the type of digital modulation we used (PI/4 DQPSK) was very sensitive to phasing and amplitude issues otherwise easily overlooked when using analog FM. And this “equalizer guy” was a really important dude for us! My thinking is that somebody similar or a team of same is on all the Motorola, M/A-Com, etc. design teams and probably puts a lot of effort into the “equalization” of the simulcast received signals. Unfortunately the consumer scanner manufacturers probably don’t have and can’t really afford to have the same so, well, hence the problem. Basic error correction is one thing but CQPSK is pretty sensitive to phasing issues and probably something pretty dedicated to that specific issue needs to be present in the final receiver design to overcome such issues which stem from both multipath and simulcast corrupted signals.

BTW – this guy had a pretty decent dry sense of humor and I recall one time after a rather long and arduous day when we were discussing digital vs. analog on RF when he said: “Well, if we had started with digital we’d be going to FM now!” I know he was joking buuuuut…

-Mike
 

Tom_G

Member
Joined
Dec 19, 2002
Messages
28
Location
Rocky Hill, CT
I know there is talk here of specific systems but the PSR-500 and 600 are the best sounding digital scanners available.
I have tried all the radios available and the GRE's are by far the best sounding and tracking.
 

beischel

Member
Joined
May 19, 2007
Messages
292
Location
Pierce Township, Ohio
ScanFan1 said:
I also am having the same problem with the signal cutting in and out on both dispatch and mobile unit's also. I tried GRE'S 800 mhz antenna to see if that would make a difference but it did not. I have a uniden 996T and I don't have that problem with it, and I am using the indoor antenna that came with the uniden so I know that it is not a issue with not having an outdoor antenna. I'll probably will email GRE to see if they might have a solution to the issue. If I get an answer to the problem, I will be sure to post it.

I have both the 996T and the 500 and the problem happens with both scanners, but unlike you, the problem is far worse for me on the 996T. In fact, I just ordered a PSR-600 since I have been so fed up with the problem on the Uniden 996T. It should be here in the next few days so I will be able to do more side-by-side comparisons. In all cases I am using the stock antennas attached directly to the radios.
 

Statevillian

Member
Joined
Aug 21, 2006
Messages
255
Location
Chicago, IL.
I concur

Tom_G said:
I know there is talk here of specific systems but the PSR-500 and 600 are the best sounding digital scanners available.
I have tried all the radios available and the GRE's are by far the best sounding and tracking.

Our State of Illinois Starcom21 system has a mind of its'; own. 700/800Mhz trunked and in the Chicago area we have a few simulcast sites. I agree the 500 is far better with reception. I have also noticed that bad weather also makes some of the transmissions choppy, get cut off in mid transmission or not get received at all. This has been evidenced by some users too as they will comment about it themselves. Sometimes I wonder if part of the loss of those transmissions (not decoding right away) on the GRE are due to the Object Oriented concept. I am not a techno whiz but I have noticed it with systems I program where I have MANY, MANY objects or talkgroups for the 500 to scan for. Just a thought.
 

AZScanner

Member
Joined
Dec 19, 2002
Messages
3,342
Location
Somewhere in this room. Right now, you're very col
AZScanner said:
I could confirm the idea by writing a quick and dirty test program for my 796 which would essentially do the same thing. Think I'll try it just for funsies.

Just an update on that, I did write the program and it did seem to help but not very much - certainly not enough to warrant running it full time. Looks like the Yagi solution is the best bet.

-AZ
 

DonS

Member
Joined
Jun 17, 2003
Messages
4,102
Location
Franktown, CO
Statevillian said:
Sometimes I wonder if part of the loss of those transmissions (not decoding right away) on the GRE are due to the Object Oriented concept.
Highly unlikely.

Having lots of TGRPs in a single TSYS just means it takes slightly longer for the scanner to decide that a TGID it's heard on the CC is "desired", and that the scanner should tune to the voice frequency.

"Slightly longer" is on the order of a few milliseconds. For example, a TSYS with 1000 TGRPs programmed takes about 4.4 milliseconds longer to tune to the VC than one with 10 TGRPs.

EDIT: oh... that 4.4 mS is the maximum time it would take, if the searched-for TGID was the last one checked.
 
Last edited:

JT-112

Member
Joined
Jan 11, 2004
Messages
492
Minor nit - there aren't any packets in the P25 air interface, but rather frames.

Packets are individual and distinct, and can stop at any time, and re-start at any time. Frames come in a continuous stream (e.g., while the PTT button is pressed).

If GRE is watching this board, it would be nice to know if they know what the problem is. I'm currently leaning towards error correction not being as robust in scanners as compared to the actual P25 radios. It doesn't take many wrong bits to create bad audio.
 

Statevillian

Member
Joined
Aug 21, 2006
Messages
255
Location
Chicago, IL.
Thanks Don!

DonS said:
Highly unlikely.

Having lots of TGRPs in a single TSYS just means it takes slightly longer for the scanner to decide that a TGID it's heard on the CC is "desired", and that the scanner should tune to the voice frequency.

"Slightly longer" is on the order of a few milliseconds. For example, a TSYS with 1000 TGRPs programmed takes about 4.4 milliseconds longer to tune to the VC than one with 10 TGRPs.

EDIT: oh... that 4.4 mS is the maximum time it would take, if the searched-for TGID was the last one checked.

Good. I can put that theory...and that concern...to rest. BTW, I use Win500 and I love it. Great product. You have no idea how simple you made things for me.
 

beischel

Member
Joined
May 19, 2007
Messages
292
Location
Pierce Township, Ohio
PSR-500, PSR-600 and BCD996T

The PSR-600 arrived yesterday. I bought the PSR-500 at Dayton this year and the BCD996T at Dayton last year. I was getting very frustrated with the sound quality and reception quality on the Uniden 996T. I have now done extensive comparison with all three radios. Hands down GRE wins with both radios. They are more sensitive than the 996T. They scan faster so they tend to pick up more conversations. The GRE's do not cut out near as much as the 996T. The Uniden 996T seems much more prone to audio drop outs due to interfering signals.

The original poster talked about improving audio quality. Well all I can say is it already sounds like perfection to me on both GRE models. I don't know how I tolerated the crappy audio for so long on the 996T. Even after the Uniden update, it still is not even close to the quality on the GRE 500 and 600.

Now I do have the beta firmware for the 996T and while it is an improvement of the last production firmware release, it is not there yet. Uniden has a lot of work to do to make it the same quality as the GRE digital models.
 

Statevillian

Member
Joined
Aug 21, 2006
Messages
255
Location
Chicago, IL.
The echo continues......

beischel said:
The PSR-600 arrived yesterday. I bought the PSR-500 at Dayton this year and the BCD996T at Dayton last year. I was getting very frustrated with the sound quality and reception quality on the Uniden 996T. I have now done extensive comparison with all three radios. Hands down GRE wins with both radios. They are more sensitive than the 996T. They scan faster so they tend to pick up more conversations. The GRE's do not cut out near as much as the 996T. The Uniden 996T seems much more prone to audio drop outs due to interfering signals.

The original poster talked about improving audio quality. Well all I can say is it already sounds like perfection to me on both GRE models. I don't know how I tolerated the crappy audio for so long on the 996T. Even after the Uniden update, it still is not even close to the quality on the GRE 500 and 600.

Now I do have the beta firmware for the 996T and while it is an improvement of the last production firmware release, it is not there yet. Uniden has a lot of work to do to make it the same quality as the GRE digital models.

Several of us have been saying that all along. Many people have differing opinions but, I too own Unidens...396 as far as digi. The 500 has been mind bobbling. I thought my 396 was *it* until I had that 500 up and running. Now, no comparison. Only thing I wish the 500 had was status bit function. Digital has been a very pleasant surprise.
 

ScanTheFreqs

Completely Banned for the Greater Good
Banned
Joined
Apr 23, 2008
Messages
84
ok. i know this question is a little late, but... in my case, with the simulcast system, would using an 800mhz antenna (the RS 800mhz) actually be worse then using the stock antenna??

i really dont wanna go through all the hassle of installing a yagi on my car (and making it able to rotate 360 degrees)
 
Last edited:

RoninJoliet

Member
Premium Subscriber
Joined
Jan 14, 2003
Messages
3,390
Location
ILL
Here in ILL-Starcom 700/800 its a tossup, Statevillian taught me to use the RS800 near some towers but not cell towers and use the GRE rubber duck other times, that rubber duck is very good on 700/800 and works well on VHF-UHF that comes with the GRE500....The rubber duck that comes with my Uniden 396 is useless.....
 

JT-112

Member
Joined
Jan 11, 2004
Messages
492
beischel said:
The original poster talked about improving audio quality. Well all I can say is it already sounds like perfection to me on both GRE models. .

I'm sure this is the case on non-simulcast systems.

Main issue - heck, maybe the only issue - is the performance and quality under simulcast systems.
 
Status
Not open for further replies.
Top