EDACS ESK Tracking solutions.

scanlist · Sep 16, 2008

Is there any way to eliminate the voice channel delay/hold while tracking EDACS ESK systems with unitrunker?

Since Denver flipped the switch last month there are a several people I know that are attempting to use unitrunker 0.1.0.57 for tracking Denver but are going stir crazy dealing with the constant barrage of disconnect tones (beeps as some call it).

Some have tried the esk.exe port of etrunker. While it does monitor the system activity it appears not to communicate with uniden radios for use as a voice tracking scanners.

Any help is appreciated.

SCPD · Sep 16, 2008

scanlist said:
Is there any way to eliminate the voice channel delay/hold while tracking EDACS ESK systems with unitrunker?

The control channel tells you when a call starts. It does not tell you when a call ends. This can be inferred by (a) call starts again on a different channel (b) a different call starts on the current channel and (c) when the voice radio reports squelch or loss of carrier.

There is a program that filters out the "dotting" tone but that requires piping the voice audio through the computer. Look for a program named "GE Ease" - vintage 1998 or so.

scanlist said:
going stir crazy dealing with the constant barrage of disconnect tones (beeps as some call it).

I get this on some non-ESK systems. You can hear a buzz of ANI data at the start of the call and the EDACS tone at the end of the call. It does not botther me but perhaps I've gotten used to it.

scanlist said:
Some have tried the esk.exe port of etrunker. While it does monitor the system activity it appears not to communicate with uniden radios for use as a voice tracking scanners.

It probably only works with some of the older Unidens like the '245 and '895.

Does anyone from Denver have a sample recording of this? Does it really sound that bad?

scanlist · Sep 17, 2008

Unitrunker said:
The control channel tells you when a call starts. It does not tell you when a call ends. This can be inferred by (a) call starts again on a different channel (b) a different call starts on the current channel and (c) when the voice radio reports squelch or loss of carrier.

Back in the day, as they say, I used the old school dos etrunk program that would drop the voice channel based on the CC data right at the first disconnect tone. If the source code is still around somewhere the author figured out a way via the CC to do this. Unfortunately I'm not a coder.

There is a program that filters out the "dotting" tone but that requires piping the voice audio through the computer. Look for a program named "GE Ease" - vintage 1998 or so.

Almost forgot about that old solution using the sound card. Yes it does the job. My old etrunk setup was a bc895 with the G-whiz board. It was all convoluted back then but it worked.

I get this on some non-ESK systems. You can hear a buzz of ANI data at the start of the call and the EDACS tone at the end of the call. It does not botther me but perhaps I've gotten used to it.

Using unitrunker the initial buzz/burst at the beginning of voice transmissions is not present. Just the entire disconnect tones/dotting is coming through at the end of voice transmissions unless the TG moves to another LC otherwise you hear 5 disconnect tones in a row after each voice transmission. "Beep beep beep beep beep".

On esk.exe:

It probably only works with some of the older Unidens like the '245 and '895.

One individual is using a 245 and another is using a 895 as the trackscanner and both report that the radios do nothing. When they use DOS trunker or etrunk they work. Maybe it's something off kilter in the etrunker port to esk version.

slicerwizard · Sep 17, 2008

The problem can be dealt with by giving users the option of setting a timeout value for tuned comms on EDACS systems. The value would specify how many ms to wait after each update OSW on the CC before moving the voice receiver off of the voice channel. Set it too low and comms get chopped up; set it too high and you hear the whole disconnect sequence. The timer can operate independently of any existing call processing / display logic.

A per-system timeout value might be best. A value of zero could disable the timer (e.g. use existing logic only).

Obviously, the best solution is to monitor the voice receiver audio for the dotting sequence, but I doubt most users want the extra audio plumbing.

SCPD · Sep 17, 2008

scanlist said:
Back in the day, as they say, I used the old school dos etrunk program that would drop the voice channel based on the CC data right at the first disconnect tone.

The old Etrunk code operates exactly as Slicerwizard describes. The issue with Unitrunker may indeed be the lease time I give each voice call. I see a TTL of 2.5 seconds. The program will terminate the voice call 2.5 seconds after the last continuation message. Assuming continuation updates once per second, the program tolerates missing every other continuation message (due to noise, poor reception) without erroneously dropping the voice call.

Reducing this TTL value to something like 1.5 seconds leaves no margin for poor signal quality. Miss a continuation message and your conversation gets cut off. I have some "wiggle" room with the fractional portion of the delay. I could use 2.1 or 2.2 instead of 2.5 (or 1.1 or 1.2 instead of 1.5) seconds. Reducing the fractional portion may do the trick here.

slicerwizard said:
the best solution is to monitor the voice receiver audio for the dotting sequence, but I doubt most users want the extra audio plumbing.

Agreed.

Folks in Denver may be interested in the next Unitrunker release which includes voice following.

PiccoIntegra · Sep 18, 2008

Why not use the squelch status of the voice radio to determine lease time? 2.5 secs seems to be a sweet spot for missing calls, especially when radio traffic is very busy. This is one of those annoyances that I'd love to see fixed. :lol:

SCPD · Sep 18, 2008

PiccoIntegra said:
Why not use the squelch status of the voice radio to determine lease time? 2.5 secs seems to be a sweet spot for missing calls, especially when radio traffic is very busy. This is one of those annoyances that I'd love to see fixed. :lol:

The old program does this (for those receivers that provide squelch status). This frees the voice receiver a fraction of a second sooner to chase the next call.

The problem with the EDACS disconnect tones is ... carrier is present during these beeps so the receiver squelch status is no help.

BTW - those beeps aren't really tones. They're data.

scanlist · Sep 19, 2008

Unitrunker said:
The issue with Unitrunker may indeed be the lease time I give each voice call. I see a TTL of 2.5 seconds. The program will terminate the voice call 2.5 seconds after the last continuation message.

Reducing this TTL value to something like 1.5 seconds leaves no margin for poor signal quality. Miss a continuation message and your conversation gets cut off. I have some "wiggle" room with the fractional portion of the delay. I could use 2.1 or 2.2 instead of 2.5 (or 1.1 or 1.2 instead of 1.5) seconds. Reducing the fractional portion may do the trick here.

This makes sense to me about why we hear the entire set of disconnect tones/dotting. 1.1 would probably yield the intial VC drop/disconnect tone with an ideal signal scenario.

I do like slicerwizard's recommendation for a user selectable timeout setting to tweak per system.

pr57001 · Sep 23, 2008

I would like to build an application to detect the dotting and silence audio (I have read of the GE-Ease program but could not find an active download link and would like to write a new one).

I have a correct 9600 bps stream, I believe the dotting sequence is something like 800+ bits of 1010101010101? Is this correct? Will this be triggered accidentally by dotting used on any other working channel signaling?

slicerwizard · Sep 23, 2008

pr57001 said:
I believe the dotting sequence is something like 800+ bits of 1010101010101? Is this correct?

It is a 1010... sequence, which means the audio is just a steady sine wave. Record a sample with a program like GoldWave and just look at it.

Will this be triggered accidentally by dotting used on any other working channel signaling?

Not if you do it right. The more you clean up the signal (e.g. low pass filter), the tighter your detection threshold can be.

scanlist · Sep 23, 2008

Something to think about. This might eliminate the need to kludge.

The old etrunk.exe dos program nails it immediately when the TG is released an all you heard was a split second of the first disconnect tone then immediately to mute or the trackscanpark freq on the tracking scanner until the next LC jump for the TG being monitored.

Since I'm not a coder I would believe that the source code for the etrunker DOS program holds the key in making life easier for EDACS tracking with the current tracking program offerings.

What would help out a couple of locals (and others) is if someone were able to make fixes to the esk.exe DOS program where it would communicate properly with the BC245 and 895 for trackscaning purposes which the etrunk program does flawlessly.

SCPD · Sep 23, 2008

pr57001 said:
I have a correct 9600 bps stream, I believe the dotting sequence is something like 800+ bits of 1010101010101? Is this correct?

Working channel end-of-message burst is 32 bits and looks like this (grouped into sets of four):

Code:

1010 1000 1110 1101 0101 0101 0101 0101

The message is repeated 16 times - 512 bits long (a little over 50ms). On a 'scope - it will look and sound like a 4800 hz tone with some energy at 1200 hz.

Five beeps at the tail end of a call suggests message trunking instead of transmission trunking. The extra beeps are additional data. Radios hold until a final "drop" message is sent or the call resumes.

There is a pure dotting sequence of 200ms or so AFTER the EOM and any update messages delivered during the hold time but by then, most of the "noise" has transpired.

pr57001 · Sep 27, 2008

Unitrunker said:
Working channel end-of-message burst is 32 bits and looks like this (grouped into sets of four):

Code:

1010 1000 1110 1101 0101 0101 0101 0101

The message is repeated 16 times - 512 bits long (a little over 50ms). On a 'scope - it will look and sound like a 4800 hz tone with some energy at 1200 hz.

Five beeps at the tail end of a call suggests message trunking instead of transmission trunking. The extra beeps are additional data. Radios hold until a final "drop" message is sent or the call resumes.

There is a pure dotting sequence of 200ms or so AFTER the EOM and any update messages delivered during the hold time but by then, most of the "noise" has transpired.

Thank You. I am having intermittent success with this. Is there a different behavior if the channel is presently analog or digital? Do you have any more detail on the other working channel signaling? Mute/Un-key etc? Is your information from the patents or experimentation?

SCPD · Sep 28, 2008

pr57001 said:
Thank You. I am having intermittent success with this. Is there a different behavior if the channel is presently analog or digital? Do you have any more detail on the other working channel signaling? Mute/Un-key etc? Is your information from the patents or experimentation?

My interest lies in the control channel more so than the voice channel. I don't know if the "in band" signalling on the working (voice) channel behaves differently for ProVoice vs. analog voice calls.

xnaron · Jan 5, 2014

Did you ever find a solution scanlist?

vans113 · Jan 27, 2014

I monitor a edacs with Esk and pro voice system here using unintrunker and dsd I have unitrunker set to control the scanner and who I want to hear so I don't hear them. If I set my scanner to scan the frequencies then yes I hear the end of transmission

Sent from my iPhone5 using Tapatalk

Thayne · Jan 27, 2014

This horse is dead now but it was sure fun figuring out the answers---p:

EDACS ESK Tracking solutions.

scanlist

Scanning since the 70's to today.

SCPD

QRT

scanlist

Scanning since the 70's to today.

slicerwizard

Member

SCPD

QRT

PiccoIntegra

Member

SCPD

QRT

scanlist

Scanning since the 70's to today.

pr57001

Member

slicerwizard

Member

scanlist

Scanning since the 70's to today.

SCPD

QRT

pr57001

Member

SCPD

QRT

xnaron

Member

vans113

Member

Thayne

Member

Similar threads