Whither Richmond/San Pablo Trunked?

[antoine]

after the updated freqs my scanner beeps after some of the transmissions is this normal?

 

[linuxwrangler]

after the updated freqs my scanner beeps after some of the transmissions is this normal?

They are working on the system. You will still hear lots of radio-tech test-counts. Talked to one of the EC officers this morning and he said that they are still having intermittent static/garble/beep problems. Seems to mostly be related to 860.7125. When that is in the mix, things sound bad. When it is not, system sounds fine.

So be patient, it's probably not your scanner.

 

[TenOne]

Thanks for the info linuxwrangler. I’m in the flatlands in North Albany. The new frequencies were working out great. The beeps started yesterday on my system for the very first time. There’s five beeps in a row that last around 4-seconds. I conducted a test, which lasted exactly 1-hour while monitoring radio traffic for SPPD/ECPD. I counted the number of times the mic was keyed either by dispatch or a patrol unit. The mic was keyed 252 times. The beeps occurred 19 times immediately following broadcast by a patrol unit. The beeps also occurred 21 times immediately following broadcast by a dispatcher. Out of the 252 times a mic was keyed, the beeps occurred 40 times total, which I think works out to about 16% of the 1-hour time period where the "beginning" of a transmission was cut short. The rest of the time radio transmission between dispatch and patrol was normal.

 

[linuxwrangler]

Someone has too much time on his hands.

But your experience is approximately correct. With 8 channels, 1 is control, 7 for talk. One of them is bad. So the expectation is 1/7=14.3% while you are seeing 40/252=15.9%. Pretty close.

 

[pretzelman]

860.7125 still a mystery??

First off, thank you TenOne for your posting of the RPD/SP trunk system. I tried them all in the order you posted them, but I'm still haveing issues with 860.7125. I get a different sounding end of transmission carrier, it's like it's not trunking properly and I have to wait to the end of the tones before the scanner moves on, have you or any other posters noticed this?

Thanks!!

 

[TenOne]

Frequencies

Sorry pretzelman but I didn't post the frequencies. inigo88 posted the frequencies so inigo88 deserves the credit. I signed up with RR to get help and advice from the experts. I'm definitely not an authority on scanners or anything electronic. Thanks again inigo88 for the freqs and thanks linuxwrangler for your previous advice. Any update on the beeps?

 

[pretzelman]

Thank you TenOne for the correction. By the way as of today I'm still hearing that 5 beep tone on 860.7125, has anyone been able to lick this problem? I've tried leaving out the named freq, but I still seem to miss parts of the radio traffic.

Pretzelman

 

[inigo88]

If you leave out that freq, then you will miss radio traffic on the system. That is, in fact, the object of trunking - with each conversation on a talkgroup constantly hopping between frequencies on the system to spread the load and make efficient use of the frequencies (basically the whole idea is that not everyone will want to talk at once, so you put a lot of channels in the system in the form of talkgroups and not enough frequencies to support them all at once - so if someone from each talkgroup all keyed their mics at the same time most would get a busy signal). The control channel tells their radios (and your scanner) which frequency to jump to for each transmission on a given talkgroup milliseconds after the PTT is depressed, so to everybody it sounds like you've been on one channel the whole time (when in fact you've been hopping between 7 voice frequencies - the 8th allotted to the control channel, which rotates in its logical channel # assignment).

Linuxwrangler said:

But your experience is approximately correct. With 8 channels, 1 is control, 7 for talk. One of them is bad. So the expectation is 1/7=14.3% while you are seeing 40/252=15.9%. Pretty close.

Like we've already talked about, if you lock out 860.7125, you're going to miss approximately 15% of everything said on the system. It's an unfortunate fact. Your options are, listen to the beeps 1/7th of the time since they seem to be the result of a technical error somewhere during the system's rapid expansion - OR - lock out 860.7125 and miss 1/7th of the radio traffic (and possibly something fun and or important).

Linuxwrangler said:

They are working on the system. You will still hear lots of radio-tech test-counts. Talked to one of the EC officers this morning and he said that they are still having intermittent static/garble/beep problems. Seems to mostly be related to 860.7125. When that is in the mix, things sound bad. When it is not, system sounds fine.

So be patient, it's probably not your scanner.

Again, it's been previously talked about in the previous two pages of this thread.

Any new developments though guys?

-Inigo

 

[linuxwrangler]

Any new developments though guys?

Well, the radio techs seemed quite busy Sunday afternoon. Lots of traffic like "OK give me zero-dB....Looks good. Put five back in service and make it the control channel and we'll move to six."

But the system doesn't seem to sound any better.

'Course they do have several sites and they probably have to get each site tuned individually and then all sites adjusted as a system so I guess there is still work to be done.

Also, has anyone listened for the morse identifier to see if they have changed ID to WPVN860 (or something else)? RR's additional info popup still shows WPGR333 but that license does not have the new frequencies like WPVN860 does.

 

[TenOne]

Some observations

Monday, 1 OCT 2007, radio traffic for RPD/SPPD/ECPD/PPD/FIRE:

~1345: Lot of tech chatter on Talk Group 02-125.

~1346-1356: Talk Group 02-041, exactly 17 radio transmissions between dispatch and patrol occurred where the 5-beep interference did not occur.

~1358-1406: Talk Group 02-041, exactly 18 radio transmissions between dispatch and patrol occurred where the 5-beep interference did not occur.

Whatever techs were doing around these time intervals seemed to be working in my opinion. So far, these are the longest time intervals I've experienced at my location where the 5-beep sound wasn't heard.

 

[pretzelman]

5 Beeps

I've heard from a good source that the users of the trunk system can not hear the 5 beeps that we are still hearing, so I do not think they are in a real hurry to make it easier for us scanner buffs to listen in without the 5 beeps. I'm guessing they will get it fixed sooner or later. If anyone has different information please correct me. When I hear more I will post.

 

[inigo88]

I concur. A friend with a GE EDACS radio is not getting the multiple beep problem. I listened to Richmond last night and LCN 8 was down to a beep or two at most following each transmission, making a huge measurable imporvement to last time.

 

[linuxwrangler]

I'm still hearing all five beeps. In chatting with some of the local officers and by the fact that the on-air conversation apparently continues at the same time I'm just hearing beeps, I also surmise that they aren't hearing them.

I know very little about EDACS - perhaps someone can enlighten me. What purpose do the beeps serve? Could these "harsh" beeps actually be within spec? How does the scanner or other radio normally skip the beeps (control channel info or are the beeps themselves the signal that the transmission has ended)?

I have not, till now, seen any need to update my firmware. Is an update to the latest 396t firmware likely to improve the situation? Apparently the GE radio is not adversely affected. What about various scanners? Please post your observations with scanner model and firmware level.

 

[rambob]

My Pro-95 is still adversely affected.