LTR Trunker?

[exkalibur]

Hi guys;

I'm going to be needing to monitor an LTR system in the semi-near future. I don't have any system details as of yet, except that it's UHF.

What are my options for a Trunker-like program? I've only ever used the LTR-trunker program, but wasn't too impressed.

Thanks

[DaveNF2G]

LTRTrunker is the only software (AFAIK) that will track all flavors of LTR trunking. I'm not sure what would be unimpressive about that. :-)

[N0JRD]

Will the LTR Trunker work on LTR Passport systems?

[wayne_h]

Originally Posted by KC0ZGT

Will the LTR Trunker work on LTR Passport systems?

Yes, along with Multi-Net also.

[exkalibur]

Originally Posted by DaveNF2G

LTRTrunker is the only software (AFAIK) that will track all flavors of LTR trunking. I'm not sure what would be unimpressive about that. :-)

The fact that LTRTrunker (as well as regular Trunker) just plain suck when it comes to error correction and filtering out bogus decoded data.

[rescue161]

Originally Posted by exkalibur

The fact that LTRTrunker (as well as regular Trunker) just plain suck when it comes to error correction and filtering out bogus decoded data.

I'm running LTR Trunk here with no problems. Maybe it's your data slicer that is the problem? I've never used regular Trunker because T4Win and UniTrunker have always worked very nice for me. I wish Rick would implement LTR into the next UniTrunker release! ~hint~ ~hint~

[DaveNF2G]

Well, your original posting asked for options. That has been answered - your only option is LTRTrunker. Continuing to complain about its performance will not create any additional software choices.

If I were a moderator, I would say that this thread has run its course and lock it.

[DaveH]

Originally Posted by exkalibur

The fact that LTRTrunker (as well as regular Trunker) just plain suck when it comes to error correction and filtering out bogus decoded data.

So sorry it is not to your liking...let's see...that leaves you
*zero* alternatives.

Eric not only adapted Trunker to LTR, he came up with a filtered
data slicer circuit. Regular slicers can give lots of false decodes,
but you'll notice I'm not complaining that I get them because I haven't
built one yet.

LTR frames do have a checksum but I can't say if LTRTrunk uses
it to drop bad frames, probably not. If not, someone could modify the
program to do so.

The best you can do without receiver remote control is scan
the channels conventionally with delay off, and build up a list
of Group IDs (if that's what you're looking for).

With all those "M" radios, you can't afford a cheap LTR scanner, or
perhaps a "real" LTR radio e.g. HT1250LS or whatever?

I tend to agree with DaveNF2G, not much left to say in this
thread.

Dave

[exkalibur]

Originally Posted by DaveH

With all those "M" radios, you can't afford a cheap LTR scanner, or
perhaps a "real" LTR radio e.g. HT1250LS or whatever?

I never said I didn't have a /\/\ radio that can do LTR. I have several. But that isn't going to help me track a system. There's a new UHF LTR system in town here that nobody knows about (it's not even licensed on TAFL), and I'd like to see what I can do about mapping it out.

LTRTrunker is "okay", but but it's lacking a lot of things that would make it better, IMHO. A program like Treport for LTR would just plain kick ass. Also, LTRTrunker was never intended to be a stand-alone release, it even states in it's help text that it's a proof of concept program, and will be expanded/worked on. From what I hear, there's another LTR decoding program in the works that will leave Trunker in the dust. We shall see what happens.

[slicerwizard]

Originally Posted by DaveH

LTR frames do have a checksum but I can't say if LTRTrunk uses
it to drop bad frames, probably not. If not, someone could modify the
program to do so.

Is the source code available? If it is, I'll add the checksum handling. If someone posts a URL, I'll take care of it.

I tend to agree with DaveNF2G, not much left to say in this thread.

By all means, lock away. Jeez.

BTW Mike, I have an SB16-based LTR analyser we can point at that system. It uses the checksums to avoid false decodes.

[Unitrunker]

Originally Posted by slicerwizard

Is the source code available? If it is, I'll add the checksum handling. If someone posts a URL, I'll take care of it.

So ... you don't have the checksums?

BTW Mike, I have an SB16-based LTR analyser we can point at that system. It uses the checksums to avoid false decodes.

So you DO have the checksums?

Sorry, I'm just easily confused.

Eric magnanimously posted the checksums for LTR and Passport a few years ago (just before the switch from trunkedradio.net to radioreference.com). Holler if you have trouble finding them.

For the record, I'm certain that Eric's code employs checksum validation of incoming frames (IIRC, LTRDump had the option of dumping all fragments - not just "good" frames). Beware, the LTR checksum is only 7 bits (but you knew that). It isn't as strong as BCH or Reed Solomon and provides zero error correcting capabilities.

-rick

[slicerwizard]

Originally Posted by rfmobile

So ... you don't have the checksums?
So you DO have the checksums?

Sorry, I'm just easily confused.

So I see!

Eric magnanimously posted the checksums for LTR and Passport a few years ago (just before the switch from trunkedradio.net to radioreference.com). Holler if you have trouble finding them.

No, I don't need them. I worked out the PassPort checksums back in 2002; LTR is quite similar, so it just took a bit of inspection of the output from a local system to figure it out.

For the record, I'm certain that Eric's code employs checksum validation of incoming frames (IIRC, LTRDump had the option of dumping all fragments - not just "good" frames).

In that case, I withdraw my offer.

Beware, the LTR checksum is only 7 bits (but you knew that). It isn't as strong as BCH or Reed Solomon and provides zero error correcting capabilities.

Both LTR and PassPort use 7 bit checksums (with PassPort adding a parity bit, IIRC) and as you say, no FEC.

[Unitrunker]

Originally Posted by slicerwizard

So I see!

Originally Posted by slicerwizard

No, I don't need them. I worked out the PassPort checksums back in 2002; LTR is quite similar, so it just took a bit of inspection of the output from a local system to figure it out.

That's great. No doubt in the last five years you've made improvements.

I'd like to point out something that Mike was quick to overlook. Eric was able to figure these out and publish his results for all to see and release a working program as proof of this discovery. He deserves credit for these contributions to the hobby - something the folks responding to exkalibur's original question seem to understand. Specifically in the area of LTR, I can think of only one other example (from "opus"). Since 2002, those are the choices we've had ... for which I am grateful.

Make no mistake - I appreciate your contributions too. Might you be releasing a new LTR decoder? If so, I look forward to seeing an official announcement.

-rick

[slicerwizard]

At the time, I had been working with Trident Microsystems and Motorola, investigating some of the deficiencies that existed at that point (mainly in the LS+ firmware). IMO, it wouldn't have been proper to release anything to the public, even though it had been developed on my own time and through reverse engineering, given the professional relationships in place.

And no, I haven't made any improvements in my PassPort decoder over the years, as it did what I needed it to do and I don't require it / use it any more and the local PassPort systems are gone now anyway.

I have no problem releasing an LTR decoder, but how much interest is there in a DOS-based SoundBlaster-driven decoder?

[Unitrunker]

Originally Posted by slicerwizard

I have no problem releasing an LTR decoder, but how much interest is there in a DOS-based SoundBlaster-driven decoder?

I think the big hurdle for most folks wanting to use LTR trunk is the requirement of a filtered data slicer. The demand is definitely there. I'd say ... "Go for it!" (plus Windows and Linux versions too ).

-rick

[DaveNF2G]

I agree. One of my radio computers can't run any version of Windows later than 95, so I run DOS programs on it. Right now I have one slicer for Motorola and EDACS, a 4-level for more complex protocols, and a special LTR slicer. Instead of swapping slicers and cabling around while experimenting, I'd much rather use the soundcard.

[cg]

I'd definately be interested in the LTR/Passport decoder. Public safety LTR and Passport as well as many commercial systems exist around me. Another tool in the drawer.
Thanks in advance.

chris

[Skud]

to use LTR trunker will I have to have a LTR Data Dicer or will my Discriminator tap work on my pro 95?

[DaveNF2G]

That's like asking whether you should walk to school or carry your lunch.

Yes, the discriminator tap will work, provided you have the appropriate data slicer for the type of signals you wish to decode.

[Saint]

Originally Posted by cg

I'd definately be interested in the LTR/Passport decoder. Public safety LTR and Passport as well as many commercial systems exist around me. Another tool in the drawer.
Thanks in advance.

chris

I also would like to be able to use one of the decoders for LTR Systems, I have 12 LTR Standard Systems I listen too and I don't have a filtered data slicer for the decoder programs.
Steve