Problem: "Bad" EDACS beeps prevent proper tracking

[brandon]

This was recently discussed in the California forum and I wanted to post here to see if this particular issue (see below) can be addressed/fixed with firmware. I'm not holding my breath but figured it would be worth asking

Problem? Different sounding EDACS beeps prevent the scanner from following transmissions. A few months ago our system began to broadcast beeps that sound different than usual. They are much harsher/louder in audio. And worse, these "bad" beeps prevent our scanners from following the system properly. The scanner gets hung up on the frequency containing these "bad" beeps and does not continue onto the next frequency with the talkgroup!

Here are a couple posts relating to this problem

• http://www.radioreference.com/forum...8253-edacs-beeps-richmond-trunked-system.html
• http://www.radioreference.com/forum...forum/84485-richmond-edacs-update-system.html

So far the hangups happen with nearly every scanner I tested: BC780XLT, BC796D, BC246T, BCD996T... basically any Uniden TrunkTracker. The problem also affects older GRE/RadioShack trunking scanners such as the Pro-96. The only scanners that still seem to follow systems with these "bad" beeps are the PSR-500/600 series based units made by GRE. Since the newer GRE scanners don't stumble on the "bad" beeps, I am wondering if there is a way to adjust an EDACS beep tolerance setting via firmware on Uniden models so they will start tracking again and not get stuck whenever they run into the "bad" beeps.

So far this problem has been reported with the Richmond, CA and Riverside County, CA systems. The problem with Riverside County (on Site-01 West) started a few months ago and Richmond over a year. I was hoping the "bad" beeps were just temporary, but it has been months and still occurs, so I figure they're here to stay.

I have included audio samples so you can "hear" what I'm talking about.

• Normal EDACS beeps which the scanner handles just fine - audio sample
• The "bad" EDACS beeps that cause problem - audio sample
• Here is a recording of my BCD996T Scanner getting stuck because of these "bad" EDACS beeps. This was in trunked mode!!! This is what you would expect to hear if sitting in conventional mode, but this was not the case here. Definitely a problem

I don't even know if this is possible to fix via firmware update, but wanted to see what the Uniden experts think. Assuming the new scanners coming in 2009 are similar to previous models, they may suffer from the beeps too. I have many Unidens so please tell me it can be fixed

Thanks for taking the time to read this lengthy post.

 

[GTO_04]

I've never heard the "bad" EDACS beeps like that on my local EDACS system.

The normal EDACS beeps were passed through on my 396 but that was fixed with a firmware
update from Uniden and it is no longer an issue. If the 996 had similar issues it would also be
fixed with a firmware update. Do you have the latest firmware update for your 996. There is a
thread regarding all the latest firmware updates.

The buzz you hear at the beginning of some transmissions is not in your scanner IMHO. That is
in their system and you will sometimes hear that on user radios.



GTO_04

 

[brandon]

Yeah I used to have the same problem with the normal beeps but the firmware update from last year fixed that. I should point out that the "bad" beep only happen on one channel (LCN #3 for our West system). The other 9 channels still have the regular beeps following transmissions, which scanners handles just fine in trunking mode. It's just when the scanner stops on LCN #3, which contains the "bad" beep, it is unable to continue tracking until the beeps time out.

As for firmware, I am using firmware 3.02.00 on the BCD996T. My BC796D and BC246T are at their latest firmware revs too.

Thanks.

-Brandon

 

[SCPD]

Us people in Tasmania (Australia) still have issues with the EDACS beeps on the 396T, none of the firmware upgrades we have had have fixed them, one of the reasons I got the DTS-96 (pro 96 clone)

Paul

 

[W8RMH]

EDACS systems have what is called "scannerbusters", the tones that you hear. It is possible these tones are being upgraded to defeat any firmware used to go around it.

 

[slicerwizard]

They are much harsher/louder in audio.

It's just a lower frequency disconnect beep (about 540 Hz)

I don't even know if this is possible to fix via firmware update, but wanted to see what the Uniden experts think.

I think you should provide the scanner manufacturers with some good quality (e.g. not 8 bit 11 kHz sampling) .wav files taken from a good discriminator tap.

 

[brandon]

Audio sample

It's just a lower frequency disconnect beep (about 540 Hz)



I think you should provide the scanner manufacturers with some good quality (e.g. not 8 bit 11 kHz sampling) .wav files taken from a good discriminator tap.

Hi slicerwizard,

Thanks for the suggestion. Here is the unfiltered audio taken from the disc on a PCR-1000.

Bad Beep - http://www.solarix.net/audio/edacs_bad.wav
Normal Beep - http://www.solarix.net/audio/edacs_normal.wav

I'm not an expert in this audio stuff, so hopefully this format is OK and can be of assistance to the manufacturers.

Cheers
-Brandon

 

[UPMan]

Neither of the files you link exist.

From your descriptions, it sounds like something might be out of whack on those repeaters. It would be interesting to know whether system radios are operating correctly when they hit those freq's.

 

[brandon]

Ooops...thanks for letting me know. I have fixed the URL's.

 

[linuxwrangler]

On the Richmond (and surrounds) system, the problem started when they upgraded the system and added channels. Similar to the problems brandon has noted, the "bad" beeps are on only one frequency. When the transmission ends up on that frequency, you have to wait a couple seconds and listen to the annoying beeps before the scanner continues. Usually that means that you miss any reply to transmissions on that frequency.

Since it started here with a system update and recently on the systems that brandon scans, I wonder if it is a newer format/style/whatever (or even manufacturer of equipment). The beeps have not changed in over a year so I don't think it is something the participating agencies see as a serious issue.

I believe the officers hear the beeps on occasion but not all the time like on the scanner.

When I listened to brandon's recordings, the bad beeps sound just like the ones we hear on the Richmond system.

Sure would be great if the problem could be resolved.

 

[pro92b]

The image shows the 'bad' vs. good beeps in both the time domain and frequency domain. The bad beeps have the normal 4800 Hz tone mixed with its ninth subharmonic, 534 Hz. The spectral plot shows high harmonic content and the odd harmonics of 534 Hz give the tone its edgy sound.

The 534 Hz and 4800 Hz tones are phase locked and seem to be generated from the same source. If this is a malfunction I certainly don't know what could cause it. The phase locking and the fact that the same signal is on two unrelated systems suggests it is done on purpose for reasons unknown.

On another RR thread it was noted that subaudible end transmission commands are used by system radios to initiate a return to the control channel. Scanners do not use the subaudible data but instead depend on detection of a fixed number of cycles of the 4800 Hz tone. Anything that distorts or masks the tone will disrupt scanner tracking.

The bad beeps send 8 cycles of the 4800 Hz tone and then there is an interruption every ninth cycle caused by the 534 Hz tone. GRE scanners are set to detect 5 cycles (10 bits) and then return to the control channel. Uniden scanners may be set for more bits and that would cause a failure to detect the 4800 Hz tone with the disruption every 9 cycles.

The GRE scanners can be set for 0-250 bits end tone detection and as noted the default is 10. On the EDACS systems here that is too aggressive and sometimes the scanner prematurely jumps off a voice channel before the transmission is finished. I set my PSR-500 to 20 and that seems better here - it keeps the beep short but doesn't jump off channel.

As an experiment maybe Brandon can try setting a GRE radio to 250 and see if that ruins the tracking on the bad beep channel. Select PGM + FUNC+ F3 to get to the expert menu. Scroll down to the EndtoneEDACS menu entry which should be set at 10 and change it to 250.

 

[pro92b]

To follow up on my last message I measured the beep on a Uniden BCD996T and it averages around 13 msec, or 26 bits. The bad beep never provides 26 good bits in a row so the Uniden radio does not detect the end tone.

So far this bad beep only is known to exist on two channels in two systems so it seems unlikely that Uniden will address it unless and until it becomes a more widespread problem.

When I got my PSR-500, I initially thought that the many adjustable settings were going to just be a source of confusion for the user with no real benefit. In retrospect GRE was very smart indeed to allow for comprehensive adjustments that can be used to tune the radio for unusual system configurations. The result is that GRE's latest top of the line scanners will track these two EDACS systems while none of the Uniden radios (I think that includes the BCD396XT) will.

 

[brandon]

Hi pro92b,

Thanks for your information and input.

I set EndtoneEDACS to '250' (on the PSR-500) and yes it causes the scanner to hang up on the "bad" beeps. The default value of 10 it tracks just fine.

-Brandon

 

[pro92b]

Hi pro92b,
I set EndtoneEDACS to '250' (on the PSR-500) and yes it causes the scanner to hang up on the "bad" beeps. The default value of 10 it tracks just fine.

-Brandon

Thanks for the confirmation. I think the problem is well understood now. Tracking should be ok on your system for settings of 16 or less. My preferred setting of 20 would be too high for your needs.

I should correct a mistake regarding the Uniden setting. The beep time of 13 msec is 125 bits, not 26. That doesn't change any of the conclusions about why Uniden radios do not track the bad channel.

Uniden could change the delay time in firmware but a simple downward limit change with no adjustability carries the risk of jumping off channel before a transmission is finished for some systems. Adding adjustability is a lot more work, requiring menu, software, and documentation updates beyond the firmware update itself.

 

[heyjoojoo]

For 780xlt owners, what's the solution?

 

[brandon]

Unfortunately there is no solution for the BC780XLT. Either you pray to the radio gods for the beeps to go away, or pick up a scanner that is confirmed to be compatible with the those particular EDACS systems. So far the only working scanners are the PSR-500/600 and Pro-106/197. I would love hear a report on the 396XT models.

 

[DaveeCom]

I've heard the beeps on the Richmond system too. I just bought a 396XT and was wondering what the beeps were so I came here looking for answers.

I hear them at the tail end of some transmissions. Before I read about this problem (here), I thought it was some alarm telling the PD something about the transmissions. This is my first trunking receiver so I didn't realize it was an unintended sound on their system.

Now that I've read about it, I noticed that the beeps always occur whenever a certain frequency is used but not any of the others. The randomness of the beeps happening makes sense to me now.