RadioReference on Facebook   RadioReference on Twitter   RadioReference Blog
 

Go Back   The RadioReference.com Forums > Software > Trunking Control Channel Decoding

Trunking Control Channel Decoding For discussion of installation, setup, configuration, and use of the Trunker / Unitrunker digital decoding utilities (for decoding Trunking control channels)

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old 09-16-2008, 7:54 PM
scanlist's Avatar
Member
   
Join Date: Jan 2002
Location: Greeley, CO
Posts: 1,916
Default EDACS ESK Tracking solutions.

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.
Reply With Quote
Sponsored links
  #2 (permalink)  
Old 09-16-2008, 10:19 PM
Seņor Member
  RadioReference Database Admininstrator
Database Admin
 
Join Date: Dec 2001
Location: Texas
Posts: 5,771
Default

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

Quote:
Originally Posted by scanlist
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.

Quote:
Originally Posted by scanlist
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?
Reply With Quote
  #3 (permalink)  
Old 09-17-2008, 7:18 PM
scanlist's Avatar
Member
   
Join Date: Jan 2002
Location: Greeley, CO
Posts: 1,916
Default

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

Quote:
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.

Quote:
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:
Quote:
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.
Reply With Quote
  #4 (permalink)  
Old 09-17-2008, 8:24 PM
Member
   
Join Date: Sep 2002
Location: Toronto, Ontario
Posts: 2,319
Default

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.
Reply With Quote
  #5 (permalink)  
Old 09-17-2008, 11:37 PM
Seņor Member
  RadioReference Database Admininstrator
Database Admin
 
Join Date: Dec 2001
Location: Texas
Posts: 5,771
Default

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

Quote:
Originally Posted by slicerwizard
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.
Reply With Quote
Sponsored links
  #6 (permalink)  
Old 09-18-2008, 12:17 AM
PiccoIntegra's Avatar
Member
   
Join Date: Dec 2002
Location: North Texas
Posts: 170
Default

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.
Reply With Quote
  #7 (permalink)  
Old 09-18-2008, 12:27 AM
Seņor Member
  RadioReference Database Admininstrator
Database Admin
 
Join Date: Dec 2001
Location: Texas
Posts: 5,771
Default

Quote:
Originally Posted by PiccoIntegra View Post
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.
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.
Reply With Quote
  #8 (permalink)  
Old 09-19-2008, 8:31 PM
scanlist's Avatar
Member
   
Join Date: Jan 2002
Location: Greeley, CO
Posts: 1,916
Default

Quote:
Originally Posted by Unitrunker View Post
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.
Reply With Quote
  #9 (permalink)  
Old 09-23-2008, 1:33 PM
Member
   
Join Date: Feb 2006
Posts: 25
Default

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?
Reply With Quote
Sponsored links
  #10 (permalink)  
Old 09-23-2008, 4:17 PM
Member
   
Join Date: Sep 2002
Location: Toronto, Ontario
Posts: 2,319
Default

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


Quote:
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.
Reply With Quote
  #11 (permalink)  
Old 09-23-2008, 8:13 PM
scanlist's Avatar
Member
   
Join Date: Jan 2002
Location: Greeley, CO
Posts: 1,916
Default

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.
Reply With Quote
  #12 (permalink)  
Old 09-23-2008, 9:50 PM
Seņor Member
  RadioReference Database Admininstrator
Database Admin
 
Join Date: Dec 2001
Location: Texas
Posts: 5,771
Default

Quote:
Originally Posted by pr57001 View Post
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.
Reply With Quote
  #13 (permalink)  
Old 09-27-2008, 3:32 PM
Member
   
Join Date: Feb 2006
Posts: 25
Default

Quote:
Originally Posted by Unitrunker View Post
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?
Reply With Quote
  #14 (permalink)  
Old 09-28-2008, 6:10 PM
Seņor Member
  RadioReference Database Admininstrator
Database Admin
 
Join Date: Dec 2001
Location: Texas
Posts: 5,771
Default

Quote:
Originally Posted by pr57001 View Post
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.
Reply With Quote
  #15 (permalink)  
Old 01-05-2014, 8:31 PM
Member
   
Join Date: Dec 2013
Posts: 14
Default

Did you ever find a solution scanlist?
Reply With Quote
Sponsored links
  #16 (permalink)  
Old 01-27-2014, 7:47 PM
Member
   
Join Date: Jul 2012
Location: clarksville,tn
Posts: 334
Default EDACS ESK Tracking solutions.

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
__________________
own a pro 404, and a bct 8 with a discriminator tap.
Reply With Quote
  #17 (permalink)  
Old 01-27-2014, 9:58 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: May 2002
Posts: 2,171
Default

This horse is dead now but it was sure fun figuring out the answers---p:
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 1:15 PM.


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