LTRTrunker - sudden MultiNet failure?

[DaveNF2G]

Does anyone know about possible changes to MultiNet systems that might disable LTRTrunker?

I've been tracking the Rensselaer County, NY, system for months. Yesterday, my system became unable to lock onto the control channel. I've checked the signal, which is still on the same frequency at the same strength. I have also checked out the hardware and software on LTR-Regular systems and everything else works as it should.

 

[FLANO]

Dave,

Just a thought...you've been messing around with the sample rate and the discriminator tap for Unitrunker. I don't know if that could have effected your reception, perhaps ???

I'm running LTRtrunker for the second day on our Multi-net system down here in Arizona. Still learning how to use this software. It sure would be nice if Unitrunker could handle this too

 

[SCPD]

Just a thought...you've been messing around with the sample rate and the discriminator tap for Unitrunker.

He said the program continues to work on other plain LTR systems.

Dave - you may want to send Eric a dump. Might be something new for his code to handle.

I'm running LTRtrunker for the second day on our Multi-net system down here in Arizona. Still learning how to use this software. It sure would be nice if Unitrunker could handle this too

Not this week.

-rick

 

[DaveNF2G]

Different computer and radios. There's no connection between the two problems.

 

[pro92b]

The problem appears to stem from a system failure similar to one I've seen on regular LTR. The status channel is broadcasting a continuous idle message for group 30-255. Of course there is no channel 30 in the system so it is bogus. The radio id is whacked too.

Ltrtrunk relies on the idle message to synthesize the data XOR and so it is unable to decode the control channel in the absence of a valid idle message. This problem affects both the status channel and home channel. It does not affect the other voice channels and ltrdump gets good data from them. Too bad you can't track the system using voice channel subaudible data.

System radios are programmed with the required XOR and can apparently ignore the bad data on the status channel. So the system still runs although you can no longer track it. If Ltrtrunk had a way to manually override the system ID auto-capture it also could ignore the bad data. You would have to enter the system id yourself in that case. I have confirmed that there is no change in the data XOR - same as it always was. This doesn't appear to be an insidious plot to foil the monitoring public, just poor system maintenance.

 

[DaveNF2G]

Well, at least I'm relieved to hear that it's not my gear.

Defective operation unnoticed by anyone "official"? Typical Rensselaer County. Maybe I'll give Kelly Paslow a ring tomorrow.

 

[DaveNF2G]

I just got a chance to check the system using LTRDUMP. The version I have is dated 11/10/04 - is there a newer one?

Anyway, I'm seeing something a little different from what pro92b reports, although it is likely just a different rendition of the same error. Besides all of the various "free" bursts, this line is constantly on the screen and appears on bright white:

290: 0-5-164 RID: 3518

It looks like an open mic on channel 290, GID 5-164 (neither of which exist on this system) from a Stephentown FD unit. However, no open mic should be on the air for five straight days, so obviously it's a system problem, as pro92b indicated.

Before I email the Director about this, what does this mean with respect to system operation? What should I tell him is wrong?

 

[pro92b]

What you are seeing is what I reported in a previous message. It is raw data with no data XOR applied. 290 is the raw goto channel which translates to 1016 with the xor. This is not a system channel. 5-164 translates to 30-255, the idle group for nonexistant channel 30. 3518 translates to radio id 19, also not on the system as far as I know and certainly not the usual idle message radio id. We are seeing the same thing. Version 11/10/04 is the latest Ltrdump I have as well.

 

[DaveNF2G]

Ah, OK. I'll send an email to the Comm director about this and see what he has to say.

 

[DaveNF2G]

Well, I sent the email. I haven't received any reply, but the system has returned to normal operation. Coincidence? Maybe...