Batboard

Working with an Airmux 200 doing a 4.9 link for simulcast. Signal is good at -47 or so at both ends. I am getting framing errors and yellow alarms on the T-1 connection.
Anyone worked with these before and seen this?


Any help would be great.

A near end yellow means a far end red (los). Recheck your connectors especially the rx pair at the far end. Loopback plugs in both ends will verify the radio and link are okay.

We have run new cables at both ends, replaced the units at both locations, only difference with this site is there are 2 AirMux units instead of just one. I have tried assigning channels specifically, so they were known to be different. This is 4.9 BTW. Only thing I haven't done is shut the other link off, but it doesn't get the errors.

4.9 is public safety only if I remember right so it SHOULD be clear channels, but has anyone seen how these things react to interference?

desperado wrote:We have run new cables at both ends, replaced the units at both locations, only difference with this site is there are 2 AirMux units instead of just one. I have tried assigning channels specifically, so they were known to be different. This is 4.9 BTW. Only thing I haven't done is shut the other link off, but it doesn't get the errors.

4.9 is public safety only if I remember right so it SHOULD be clear channels, but has anyone seen how these things react to interference?

Keep in mind that you may in fact HAVE an interference issue. 4.9 is shared public safety band. We run point-to-point microwave shots for voice radio on it (I know, I know... I didn't sell it and I bitched long and loud) and every now and then we have to switch channels due to interference. The equipment can automatically do this, but sometimes it does it so often it causes issues hauling the audio back to dispatch.

Also keep in mind there's a lot of different stuff running in that band. Fixed point-to-point and point-to-multipoint, helicopter video downlinks, mesh networks (PTMP), all kinds of stuff. Does the equipment have an integrated "spectrum analyzer"? What are the band conditions?

Can you put electrical (software) loopbacks on the radios and clear the alarms? If so, it could be your channel bank(s) or cable length.

Have you got the LBO (line build out) set correctly? 0-133ft is the default for most equipment. If the T1 cable between the radio (Airmux) and the mux (channel bank) starts approaching 133ft, go to the next length choice. A physical loopback on the cables will help determine if it is an LBO problem.

Do you have more than one T1 on the same cable? If so, you could have cancellation.

Is it a busy RF site? Did you use shielded cable? Sometimes RF will get into the cable and clobber the ports.

Maybe timing sources not configured correctly on each end of the link? I have goofy problems with a PTP 49600 link that uses RAD 216 boxes on each end. Still trying to get timing and jitter buffers to play nice.....

Dave

He has to get past the LOS first. However, if he is getting a quick red alarm followed by a quick yellow alarm and framing errors, then yes, it is timing / T1 slip. He hasn't told us what type of mux he is using, and whether he has declared one end as the clock source, or declared the Airmux as the source.

OK,
T-1 cable length is 3 foot or less. Units are set for 0-133.
MUX units are Harris Intraplex units that are GPS timed off a SpectraCom GPS
Timing is set transparent.

If I loop up the center site T-1 to the last hop the issues go away.
The problem this is causing is each site has 2 MTR2000 repeaters configured as base stations, the TX of course is simulcast controlled by the Harris MUXes.
The receiver side is piped back with guard tone to the prime site and runs into a JPS 12 voter. When the T-1 all this runs across T-1 circuits. The first circuit is a terrestrial T-1. Runs from Prime to site 2.
Site 2 has a microwave T-1 to site 3. This works well, very few errors over time. Then there is another microwave shot from site 3 to site 4. This is the one that is giving me fits. When the circuit drops (very short drops) the guard tone goes away and the system keys up for an instant. It's nothing more than what you would hear on ham when someone kerchunks a hammie repeater, just no reset beep as the system doesn't have one, but being commercial you knew that.

I have shut down site 4 at the voter and looped up the circuit at one end and generated data via both a WILCOM D-400 T-2 tester and the cheapie Sunrise tester the shop has. Both see the same thing,
pages of out of frame and yellow alerts in a 24 hour period. And this is with the MUX units completely disconnected and the testers generating clocking. I tried it with the RAD AirMux units creating the clocking and I get the same result. Out of Frame and Yellow alerts.

Signal levels are -47 at both ends. I have -63 on the other link and it's fine. We had -78 with 2 foot dishes, and thought that was the problem so we went to 4 foot dishes and got the -47. Signal is strong, so I don't see it being a signal issue.

The site is a multicarrier cell site. Nextel, Verizon, T-mobile and AT&T all have equipment on the site.
The other microwave link is unaffected by what ever is causing this, so I don't know that it's local interference. But I will say that early on, I was experiencing reset issues with the AIRMUX unit for this shot. Before we got dishes pointed and the link established, the unit in installation mode would run for 30 to 90 seconds and then the ODU (Out Door Unit) on the tower would reset as if had been power cycled. We replaced the ODU the IDU (In Door Unit) and the shielded ethernet cable on the tower. After all that we still had the same issue, RAD was no help so after 3 days of screwing with it and paying a tower crew we worked at getting the dishes aligned pausing when the unit would reset and continuing when it would come back up. RAD Communications never could explain that. And once we had the link up, we didn't notice it as doing this at first. Then we saw it doing it, it does key both systems (there are 2 repeaters per site) and the vote is always from site 4. The JPS voter has LED indicators that flash on and off when it occurs and it's from site 4.

Now the unit that gave us fits with the resetting was at site 3 which has two microwave links on it.

Any input is welcome.

Keith

Sounds like you did your job. Time to swap out the AirMux's in the site 4 link.

MSS-Dave wrote:Maybe timing sources not configured correctly on each end of the link? I have goofy problems with a PTP 49600 link that uses RAD 216 boxes on each end. Still trying to get timing and jitter buffers to play nice.....

Dave

Fine tuning, Dave. One of your 216's must be the master clock, the other must look to the master for timing. No if's, and's or but's about it. Then you have to dial the buffer size up and down over the course of a couple of days to get the buffer to it's sweet spot where things just flow normally. Then you'll be set.

d119 wrote:

MSS-Dave wrote:Maybe timing sources not configured correctly on each end of the link? I have goofy problems with a PTP 49600 link that uses RAD 216 boxes on each end. Still trying to get timing and jitter buffers to play nice.....

Dave

Fine tuning, Dave. One of your 216's must be the master clock, the other must look to the master for timing. No if's, and's or but's about it. Then you have to dial the buffer size up and down over the course of a couple of days to get the buffer to it's sweet spot where things just flow normally. Then you'll be set.

Thanks....

It's that way now but still have errors. Was installed wrong from the get-go. So, going to GPS clock 1 end externally as the master then massage the jitter buffer.

Dave

Bill_G wrote:Sounds like you did your job. Time to swap out the AirMux's in the site 4 link.

Bill, we have done that too. It's weird what is going on with this, of course RAD has no answers for it either.

MSS-Dave wrote:

d119 wrote:

MSS-Dave wrote:Maybe timing sources not configured correctly on each end of the link? I have goofy problems with a PTP 49600 link that uses RAD 216 boxes on each end. Still trying to get timing and jitter buffers to play nice.....

Dave

Fine tuning, Dave. One of your 216's must be the master clock, the other must look to the master for timing. No if's, and's or but's about it. Then you have to dial the buffer size up and down over the course of a couple of days to get the buffer to it's sweet spot where things just flow normally. Then you'll be set.

Thanks....

It's that way now but still have errors. Was installed wrong from the get-go. So, going to GPS clock 1 end externally as the master then massage the jitter buffer.

Dave

Let me know how that works out for you as we have the option to do that as well. We don't see ridiculous numbers of errors on the system but there are always a few.

Let's draw this out showing the T1 tx side out to site 4. The rx path should be same but reversed.

[S1-HM => T-T1 ~ T-T1 => S2-HM] xcon [S2-HM => S2-RAD ~ S3-RAD1 => S3-HM] xcon [S3-HM => S3-RAD2 ~ S4-RAD => S4-HM]

Site 1 Harris Mux (S1-HM) terminates a telco T1 (T-T1) which goes to site 2 Harris mux (S2-HM).
Crossconnect (xcon) the DS0 for site 4 within S2-HM from the T-T1 to the RAD AirMux (S2-RAD).
Over the air to site 3 AirMux number 1 (S3-RAD1) terminating to S3-HM.
Xcon within S3-HM to S3-RAD2.
Over the air to site 4 S4-RAD terminating to S4-HM.

What is reporting the yellow alarm - the Harris mux or the RAD?
Where could you insert a loopback to clear the alarm?

Bill, the yellow alarms are coming from the RAD units (actually a T-1 tester) connected to the site 4 RAD unit with the site 3 unit in loopback, totally discunnected from the Harris Intraplex.
I also get yellow alarms connected to the network monitor (t-1 monitor) port on the site 4 Harris Intraplex so it's doing the same thing with or without being connected to the system.
If site 3 - 4 link is looped back at site 3 the problems go away as far as the keying, but of course it takes site 4 off the air as well.

You're doing a local loopback at site three not going through the S4-RAD, or you're doing a remote loopback at site 4 through S4-RAD?

local loopback
[S3-HM => S3-RAD2 => internal local loopback => S3-RAD2 => S3-HM]

remote loopback
[S3-HM => S3-RAD2 ~ S4-RAD => remote internal loopback => S4-RAD ~ S3-RAD2 => S3-HM]

If a local loopback clears the alarm, then it is the last leg causing the far end LOS.
If a remote loopback clears the alarm, and you are sure it is not the cable at site 4, then it is the Harris mux T1 port, and most likely a timing issue.

Ahh I see what you are saying.
I haven't tried looping up the site 4 RAD unit, but if I loop the one at site 3 and run the t-1 tester from site 4 I still get the alarms and errors.

So, with a physical loopback at site 3 and your tester at site 4, you get yellow alarms. Again, yellow alarm means a far end problem - generally LOS (loss of sync), and generally a physical problem, but can be a clue to clock slip. Do the alarms change and become solid failures when you are testing, or do they stay intermittent? Are they periodic with semi-regular intervals suggesting clocking issues? If you reverse the setup - physical loopback at site 4 with the tester at site 3, do you get the same results? Will this model of RAD let you do internal loopbacks to isolate the cables?

tester <=> cable <=> RAD in internal local loopback (isolates and tests only the local cable and RAD T1 port)
tester <=> cable <=> S3-RAD2 ~ S4-RAD in remote loopback (tests the local cable, T1 port, and wireless link, isolates the far end cable, T1 port and Harris)

Bill ,

I haven't tried running the tests from the other end but I did loop up the far end via the RADMux software and there was not change. I still got the errors.

As far as the consistency of the errors, there is nothing cyclic to it. They re random in nature. I get some that are close together, then it will settle down, then it will get worse, but not as bad as eariler then settle down again then
go nuts and it every 5 to 10 seconds for a random amount of time.

The only thing that seems to be consistent is that the errors are very short in nature.
If you go to radio reference and monitor either the Licking County Ohio Sheriff or the Fire dispatch for the same county and listen for the system keying you will hear what I am talking about.
It sounds like someone keying the system but it's actually the system doing it by its self.

Well, until you figure out the real cause, you can change the system over to COR sense rather than pilot tone. It will mask the drop outs on the receive side. However, if site 4 has a transmitter, there will be occasional holes punched in the xmit audio.

Hello All,

New here. I came across the same situation a while back. I know this is an old post. I'll add my 2 cents worth anyways. My problem was the cat-5 between the IDU and the ODU. The cat 5 was foil shielded and not grounded to the tower. Replace with the Moto specified copper jacket shield and grounded to the tower top and bottom. (Tessco PN 318144) The hint to the issue was errors on the PTP eth port between the IDU and ODU.

That copper jacketed stuff is hard to work with.