> "Jim B." <[EMAIL PROTECTED]> wrote: > Well, I know EDACS is around 100-150 mS, where LTR is > typically 300-500mS. The baud rate, and amount of data, are > the main factors in limiting access time.
You are right on the money, but LTR is 40 bits of 300 baud data that is right about 350mS typical to be on the air. The customer is not going to notice a difference of say .150mS typical... especially when you/we/they have the typical go-head tone sequence distraction in their face for the time it takes the repeater to aquire. But what they do clearly notice is the nearly +6dB price of an Edacs radio vs an LTR format radio. > You'll also find the older motorola formats, and others, that > use a slow baud rate, will have longer channel grants. LTR is > a VERY slooooow baud rate, but not as much data is sent, which > partially makes up for it. Yep, again reference my above baud rate and data values. Everything is a trade. If we step back and look at the larger picture the question is if the various trades are worth the cost? Each person has to make his or her own choice. > Motorola formats used to be 3600 baud (or lower), where EDACS > and P25 are 9600. I'm pretty sure MPT is 9600 as well. > Jim Barbour > WD8CHL Faster baud rate is nice but much of the private ltr LMR industry doesn't want to pay non generic price tag for equipment when the difference in channel aquire time is around 150mS. Not to mention you might get locked into only one brand/mfgr of equipment paying what they want you to pay. It's great these details get out into the public eye... information is the best resource. cheers, skipp > > skipp025 wrote: > > >> If you're looking more towards public safety or 'critical > >> infrastructure' (basically utilites), you'll want something with > >> a faster access time. > > > > I'm doing all the above with LTR and it works very well. You're > > talking real world access time measured (most all trunking formats) > > in hundreds of milliseconds typical. Radios in "most" all trunking > > formats have to first transpond... > > >
