MTR3000 analogue simulcast

[John668945]

We have tried adding an MTR3000 to an existing simulcast channel that's using MTR2000 repeaters and are finding considerable changes in bulk delay between successive key-ups of the 3000. Has anyone had any experience of simulcast with the MTR3000?

[Batwings21]

Simulcast Solutions told us the MTR3000 would not work in their systems for that very reason.

[Bill_G]

Bulk delay is the ten to thirty thousand microseconds you add to all sites so you can adjust your shortest hop to match your longest. Delay is usually a function of the link to a site (usually the biggest factor) plus any internal delay in the station (usually very small). Are you saying the new MTR3K has a big change in delay each time it keys? Have you measured the internal delay of the station separately from the link?

edit to add - Simulcast Solutions would know. Interesting.

[xmo]

Did you find this issue while running tests or after installing the new station? Quite a nasty surprise!

BTW, Quantars have the same problem. I found this out the hard way - after we ordered an entire system - but at least I found it out in the lab rather than after turning the system over to real users.

If you use Quantars with a Motorola simulcast architecture - CSCI & DSM's - you use the wideband transmit input and all is well, but we were going the cheap RF linked way with Convex delay modules from Simulcast solutiuons.

This is a simple plan with a delay module at each site connected between the link receiver and the transmitter. It's a good thing I was thorough in 'staging' the system or I might not have found the variation of delay on each keyup until the system was in service. There is no fix for this other than to use the wideband input. Unfortunately, there is no pre-emphasis and splatter filtering on that input so that has to be added externally. With an all Motorola solution, the CSCI or USCI does all that.

Your best option might be to see if you can buy an MTR2000 control module as a FRU from parts and convert the station backwards.

[John668945]

Thanks for your comments. The MTR3K was added to an existing MTR2K simulcast channel as a trial prior to ordering a lot of equipment to see if there were any problems like this. It was subsequently set up on the bench and measurements taken with no infrastructure equipment connected. The delay measured appears to be stable for the duration of a transmission but if the PTT is released and re-keyed it will be different, often by several hundred usec.

The trial was using an existing Dalman Cosmos simulcast channel and the final order will be for Dalman Solar2 IP based simulcast system if the radio can be made to work. It may be possible to use the wideband input but we had hoped to put the CTCSS in there to avoid an external mixer and all the problems found when adding CTCSS before the limiter.

[d119]

Who is using the Dalman Cosmos stuff, if I may ask? What part of the country/world?

I worked on that stuff for a couple of years and found nothing but nasty headaches due to the signaling between the remotes & the simulcast host. Unless you're using microwave, I wouldn't wish that stuff on anyone.

[Bill_G]

Clackamas Co Fire OR has a Dalman simulcast on two VHF channel, and so does Yakima WA Fire Dist 5. It is different. With patience, you can make it work.

[Bill_G]

Thanks for your comments. The MTR3K was added to an existing MTR2K simulcast channel as a trial prior to ordering a lot of equipment to see if there were any problems like this. It was subsequently set up on the bench and measurements taken with no infrastructure equipment connected. The delay measured appears to be stable for the duration of a transmission but if the PTT is released and re-keyed it will be different, often by several hundred usec.

The trial was using an existing Dalman Cosmos simulcast channel and the final order will be for Dalman Solar2 IP based simulcast system if the radio can be made to work. It may be possible to use the wideband input but we had hoped to put the CTCSS in there to avoid an external mixer and all the problems found when adding CTCSS before the limiter.

The Dalman system is measuring the link delays. The ABDA system is continuously talking to the remote sites through the link - whatever it is - phone lines, microwave, dixie cups. It has no way to measure delay through a station. During TX, ABDA stops, and thus the delay screen stops. If you are seeing massive changes in the delay screen during RX, then you have an unstable link, or its total latency exceeds 32000uS.

What are you using to link to the new site?

[d119]

My issue is that standard telco circuits had a really hard time passing the signaling that's above 3000Hz. It was a constant fight to keep the circuits up.

[Bill_G]

We didn't have that problem. The one telco circuit we had worked just fine. We had paging tones that encroached the control signalling band of the Dalman protocol, and we had to reprogram lots of pagers. We ran into the 32000uS max delay limit through more than two hops of Ledr 900M links. We ran into RAD mux encoding compression clobbering the Dalman protocol. And we ran into external PL encoder alignment issues (Royal PITA).

The Dalman system is a great candidate if you are trying to simulcast a bunch of sites with different models of transmitters. It's parametric audio equalization is fantastic. You can make every site sound the same. Just dial it right in. But, if you have the same model radio at all sites with the same links, then go with Harris Intraplex. It rocks. It has some strange reverse polish notation programming squirrelliness going on setting up the alarm and monitoring system. But, the rest of it is a thing of beauty. Sounds super.

[John668945]

The Dalman Cosmos simulcast kit is quite old now and as you've pointed out needs good quality telco circuits. Most systems are installed in Europe, Australia and South Africa where the normal telco circuit bandwidth is more like 300-3400Hz. The group delay equalizer in Cosmos has a huge capacity to clean up even quite poor quality circuits but it does need a network analyzer to set it up, you'll really struggle without one. I've spent hours listening to sweeping tones equalizing a big system. As was pointed out above it can't adjust for delay in the transmitter, only as far as the line interface tray. The Dalman Cosmos system has been superseded by Solar and now Solar2 which uses all IP links and external 1PPS for synchronizing. As long as you use all the same transmitters the only setup you have to do is read off the network latency to the furthest site on the Engineering Terminal and set the buffer time accordingly. One setting system wide, job done. It still won't work if the transmitters have variable delay though, nothing will.

The system where the MTR3000 was tried out in South Africa had been stable previously with all MTR2000s, one was swapped out to try it. Sending a frequency sweep over the air and normalizing the network analyzer the phase stayed constant at 0 degrees over successive sweeps until the MTR3000 was de-keyed and re-keyed at which point the phase was a straight line, 0 degrees at 0Hz (extrapolated as the circuit won't go that low of course) but increasing steadily as the frequency increased. A bulk delay change. Different slope every time the TX was keyed on.

[Bill_G]

Good. You used the little gem analyser to show that phase changed through the MTR3k. I like that tool. It will definitely show you there has is a difference. It just drives you slowly insane.

boodahloodahloodahloodahloodahleedileep boodahloodahloodahloodahloodahleedileep boodahloodahloodahloodahloodahleedileep.

But, when you're done, the system is airtight.

[desperado]

You have to wonder if this was actually engineered into the new radio to force the sale of a higher tier radio for the same use.

[techmi]

Has there been any further development on this subject. I am currently at the IWCE and am hoping to be able to talk with Ed of Simulcast Solutions on this subject and wanted to find out if anyone has had sucess with an All MTR3000 simulcast system utilizing Harris Mux's and PTP (T1/IP) Links, or of any other insights on a work around or things that they have tried and didn't work.

[John668945]

I've not heard any more but I am waiting to hear back from someone who is going to try fitting an MTR2000 control board in the MTR3000 to see if that works any differently (or catches fire etc). It would be very interesting to hear what Ed has to say if you wouldn't mind posting his comments back on here.

[desperado]

OK, I have converted a number of MTR 2000 units into MTR 3000 units.
The RX, Exciter and control board are ALL different.
Basically the entire center of the repeater gets swapped. The parts are NOT interchangeable unless you do all three.

Another option is to talk to shops that are doing alot of MOTOTRBO MTR conversions and see if you can buy the removed parts.
Ours are NOT for sale for obvious reasons. I have a 5 site, 2 radio per site Simlucast system in VHF that I am hoarding the parts for in case they decide to go with another site at some point, which has been discussed.

[techmi]

Spoke with Ed of Simulcast Solutions, he was of the same opinion as those stated here on the board, i.e. hasn't been sucessfully deployed. Spent last two days with a MTR3000 and MTR2000 doing side by side comparasions, Untilizing a Convex TIMMS we measured the delay through the MTR's and came up with the following results. MTR2000 audio delay thru the radio was rock solid at 2.141 mSec, audio delay thru MTR3000 varied between (low) 23 to high 43 mSec, generally delay was fairly stable between power cycles i.e. once the 3000 was booted delay was "generally" the same from one keyup to the next but the delay would change between power cycles or resets. Every conceivable setting in the RSS was tried in order to get a stable delay time with no significant changes noted. Unlike the 2000 the 3000 exciter is NOT continually "up", we tried a hardwire external PTT and then used the Final PA Bias enable line as our PTT without any sucess. Bottom line is that we have decided that the 3000 is a digital radio with some analog features and is unsuitable for simulcast operations at this time.

[d119]

Spoke with Ed of Simulcast Solutions, he was of the same opinion as those stated here on the board, i.e. hasn't been sucessfully deployed. Spent last two days with a MTR3000 and MTR2000 doing side by side comparasions, Untilizing a Convex TIMMS we measured the delay through the MTR's and came up with the following results. MTR2000 audio delay thru the radio was rock solid at 2.141 mSec, audio delay thru MTR3000 varied between (low) 23 to high 43 mSec, generally delay was fairly stable between power cycles i.e. once the 3000 was booted delay was "generally" the same from one keyup to the next but the delay would change between power cycles or resets. Every conceivable setting in the RSS was tried in order to get a stable delay time with no significant changes noted. Unlike the 2000 the 3000 exciter is NOT continually "up", we tried a hardwire external PTT and then used the Final PA Bias enable line as our PTT without any sucess. Bottom line is that we have decided that the 3000 is a digital radio with some analog features and is unsuitable for simulcast operations at this time.

I see an FSB on the horizon...

[techmi]

FYI No you cannot retrofit an MTR3000 with MTR2000 parts (SCM, Exciter, RX and Wireline) removed from an MTR2000 as part of a MotoTRBO upgrade. Station will power up, and you can access the station with the MTR2000 RSS but the MTR2000 parts will NOT recognize the remaining MTR3000 parts and you will be in an "RSS Mode Only" as reported by the Station Status dialog box. Oh well it was worth the try.

[escomm]

Looks like the question has been posed in the recently updated sales guide:

Does the MTR3000 support simulcast?
No, the MTR3000 does not support simulcast.