Batboard

I am thinking maybe one of our legacy customers will want to migrate to trunking slowly, if so, it seems like a pretty simple matter to have a device inline that records voice coming across the link, asserts PTT on the trunking system, waits for the channel to be accessed, then begins to play back the recorded audio when the channel is acquired...is there such an animal?

Birken

Try this web site for your modules:

http://www.jameco.com/

147571CK Voice Activated Switch MK103

147871 Delay Timer Module

And a little electronic ingenuity might get you what you want.

Why record? It should be just as easy to cross-band a couple of radios to carry the audio back & forth...or only one way, if desired. You could use the above mentioned delay timer, or another similar, if you find the legacy audio is being cut-off at the beginning.

I cross-banded an LCS2000 with a CDM1250 several years ago to accomplish this. The main caveat is if the trunked system is busy, or if you have some other access problem, then the trunked users won't hear the legacy users...and the legacy users won't know about it until they don't get a response & have to repeat themselves...but you'll have that same issue in your recording scenario too. Luckily, it didn't happen often.


Todd

The recording is to delay the audio from the legacy radio to the trunking radio until the trunking radio has acquired a channel. I think you understand what I meant I just didn't explain it very well. I do know that users will definitely be cut off if we just link the two together with wires, they cut themselves off even on the trunking system when they don't wait for the beep.

Birken

I guess it comes down to "training" the new users as how a Trunking system works when accessing a RF Channel. Trying to make a "Fool Proof" interface is nearly impossible. You'll always find a smarter "Fool' to screw things up.

What I am saying is there is no way for the users on the conventional side to know when a trunk has been acquired on the trunking side. So the device that links the two together has got to delay the transmission of the voice until the channel is opened.

Birken

Isn't that delay just going to cause mass confusion on both systems?

The trunking user will get messages with a random delay but the conventional system will receive messages from the trunk side immediately mixed with traffic from their own system. It would seem to only cause a lot of frustration and disrupted communications.

Just patching the systems without the recorded delay would seem to be the lesser evil if you have to do it.

Well fill me in on what I am not thinking of here. In my mind it works like this.

Conventional user wants to talk, they hit the PTT and start yapping. Delay device asserts PTT and acquires trunking channel. Delay device transmits audio over trunking channel so trunking users can hear it.

When it works the other way it's a very simple matter of a cross band repeater.

If the trunking channel is already busy the conventional users will hear it and won't transmit. If the conventional channel is busy then the trunking users will hear it after the (short) delay. If a trunking user tries to access at the same time as a conventional user, well, it happens but it also happens on trunking and conventional.

Seems to me there ought to be some sort of a pre-made chip that does this though. I did find a digital delay device for performing artists and such for $50 but the delay time is simply set with a knob. That might work because right now the trunking system's access times are always short but if it gets more heavily loaded a fixed delay might become a problem. Could always make it longer than it needs to be I guess though.

Birken

There are lots of ways to do this. Some of the more expensive solutions would be from JPS or the Motorola Lyrix2001 radio interface which is designed to deal with trunked system access delay and has a way to deal with access failure.

Also, currently Motorola is shipping VOX / delay interfaces made by Raven Electronics [ http://www.ravencomm.com/html_site/default.asp ]. The Raven box interfaces between consoles and radio channels and provides adjustable access delay.

For do-it-yourself [affordable] solutions look at:

http://www.catauto.com/dl1000.html

http://www.ah6le.net/arcom/rc210/rad.html

http://www.linkcomm.com/controllers/acc ... odelay.htm

You would have to design a way to interface one of these modules into the audio path.

Fair enough, I understand the desire for recording. Now the problem is...how do you tell the 'delay device' that a channel has been aquired? The trunking radios don't put anything out on the accessory connector that indicates when a channel grant was given & a voice channel established. You'd have to find some sort of logic level inside the radio & bring it out into the world...otherwise a simple pre-set delay would only work for "regular" access times, and not for things like busies.

Maybe it doesn't happen enough to be a concern, but if the system loads up like you say it might, then it will be.

On another note, Futurecom units go one step further...not only can they deal with the trunking access delays, but if a legacy user transmission doesn't get through on the trunked side, the Futurecom will send a series of beeps to the legacy users afterwards, to indicate the transmission didn't go through. Works nice.

Todd

I seem to recall that KR Nida had a solution for this problem. http://www.krnida.com/knrc220.htm

I am using Kenwood radios, which do have a pin on the back that indicates that a channel was granted. I became very familiar with it when I set up an MDT system which does something similar: it asserts PTT, then waits for the channel grant line to change state, then it transmits its data. Works real slick. So I was hoping there was something that would do the same already out there. It would have to have a variable delay. However everything I have seen in this thread so far has been a fixed delay. I guess that would work at least 95% of the time. If it didn't, well, they'd have to repeat. For a temporary solution, which is what these would be, it's not worth a great deal of mony anyway I guess....

Birken

Silly me, I assumed you were using Motorola.

This would be a piece of cake (and cheap!) to build up using a PIC and a digital voice recorder IC. Sounds like it's temporary though, so it may not be worth the time and effort. It is intriguing though...

On second thought, the trick would be getting it to start playing back while it's still recording...I guess an adjustable delay circuit controlled by a PIC might be a better solution.

Andy

"This would be a piece of cake..."
____________________________

There you go - a business opportunity!

You could call your new product "Tavo"

That's for Trunked access voice optimization

Actually I was thinking about something similar just this week, but for a different application. I was thinking about putting a digital recorder at the trunking controller. Take the situation where a talkgroup is busy but someone has emergency traffic. Normally (unless there is priority built in and the user has the wherewithal to utilize it), they'd have to wait until the talkgroup traffic clears before they'd get the "beep" that tells them they can talk. If there were a digital recorder, the controller could let that user talk immediately (though no one would hear it at that instant except the controller), record the transmission, and then play it back on the requested talkgroup after that group is clear of traffic. There is a tradeoff, of course. The user's transmission is delayed until the transmission in progress ceases, but they don't have to fumble with an "emergency" button. Just a thought. If only there were more hours in the day, and more disposable income to play with

Andy

I built a similar system a few years ago. I needed a "fool proof" way to play a fire alarm panel voice message over a trunking talkgroup. I used a Zetron M 55B "store & forward" delay unit. The COR input to the M55 insured an open channel before trying to send the message. I also added another second or two from an external time delay relay from NCC. Wasn't concerned as much about how fast the message went out, only that it DID go out.

Good Luck!
SZ

Thanks, that looks nifty. Bet it is expensive though. The main question is though can it store and repeat the same message simultaneously, because ordinarily it would be less than a 1 second delay, and most transmissions are longer than that.

Birken

As I remember, the M55 will start playback even as it is still storing the message. The messages I was sending through were 7 to 10 seconds long, but only buffered a second or two.

Perfect.

Birken

The Link Communications TCB-1 performs this function very well. Check it out at:

http://www.link-comm.com/security/tcb1/details.htm

and click on the "Conventional Radio to Trunked Radio" note on the bottom right-hand side of the page. All of Allen's products are manufactured and engineered very well and are reasonably priced.

Beautiful. That is EXACTLY what I was asking for.

Birken

aaknitt wrote:Actually I was thinking about something similar just this week, but for a different application. I was thinking about putting a digital recorder at the trunking controller. Take the situation where a talkgroup is busy but someone has emergency traffic. .... If there were a digital recorder, the controller could let that user talk immediately (though no one would hear it at that instant except the controller), record the transmission, and then play it back on the requested talkgroup after that group is clear of traffic. .... If only there were more hours in the day, ...

...and more repeater input receivers to make this physically possible. The reason the controller doesn't permit you to talk over the air to the site is that there's no clear channels available on which to talk.

Birken Vogt wrote:Beautiful. That is EXACTLY what I was asking for.

Birken

Wonderful. It's soooooo easy to set up, too. Good luck!

SZ$DEF wrote:The Link Communications TCB-1 performs this function very well. Check it out at:

http://www.link-comm.com/security/tcb1/details.htm

and click on the "Conventional Radio to Trunked Radio" note on the bottom right-hand side of the page. All of Allen's products are manufactured and engineered very well and are reasonably priced.

Interesting unit, I like the delay aspect of it. How does it detect the talk permit or channel grant from a Motorola radio, and can it handle something like a system busy signal?

Todd

Not being the engineer of the device....I would think that because the Motorola talk permit tones are in one range of audio frequencies for the available radio models, and the system busy signals are in yet another range of audio frequencies for the different radio models, I would think that it wouldn't be too hard to use software to, by default, hold the audio in the delay until the "talk permit tone range" is heard and then release it.

However it works - it certainly is cool stuff.

Well, 9 years later and here I am with the report.

It works as advertised. Setting up took the usual amount of playing around that any new radio interface device takes. One glitch was that on the TK690 they were using the hard set COR line and I had to move the wire to a programmed TOR line. As I am sure you are all aware COR is useless on low band what with constant noise blowing squelch and skip possibly coming in. Other than that the interface cables are just made for the radios you are using, you just tell them what you want.

The way it detects a trunking channel grant is that it listens for the talk permit tone and once it hears that it begins playing back the buffered audio. I would have done it with the channel grant logic line available with the TK-7180 but hey, it works so I don't mess with it.

I could see buying some more of these to link trunking talkgroups to outlying conventional sites, or possibly to interface a business trunking radio system to a public safety console so the dispatcher does not have to wait for the beep when they are not used to it on all their other resources.

Well, it has been up on the mountain a year and a half and the customer does not talk much. But they have snowplows out now so it is getting a workout.

Audio between the two radios is perfectly well intelligible. However, their AGC was way too hot, bringing up noise between every syllable, so I turned it off, and it still sounds like it has AGC, just not quite as bad.

I had to carefully fine tune the gain both directions. Range something like 0-100 and from memory 0-15 no effect and 25-100 no effect so the actual adjustment is in the 15-25 range, for instance and it is very touchy even then. So it would be like 21 too quiet, 24 too hot and 22-23 where to set it and it still sounds like too much AGC even though AGC is off.

But whatever. Messages are getting from one side to the other and not losing any because audio quality, just not the high quality I always strive for.

Once we get the remaining vehicles converted to the trunking system, it goes away, anyway.

I have used a NCS-C150 Two Radio Interop Switch from collcomm inc to link a P25 phase II digital to conventional analog with good success. Just thought I'd add to this thread in case it comes up in a search for somebody looking for a similar solution.

http://www.collcomminc.com/interoperabi ... tches.html

And here I am just doing stuff the lazy/easy way with console patches...

Ideally your radio used to access the trunking system should have the highest-possible PTT priority available to a subscriber, but I understand not everyone has the level of access necessary to do this.