Conventional Digital Programming vs. OFT (One Frequency Trunk) Programming

[KevinC]

An agency in my area uses many (way over a dozen) conventional P25 frequencies so I added all of them to an OFT "system" to take advantage of radio ID capturing. This was my first time to have multiple frequencies in an OFT system and it sucks. I didn't realize you couldn't pick just one of those frequencies and park on it only. The only way to accomplish this is to have each frequency in its own system. Seeing how even with the system hold time set to zero the scanner still stays on each system for around 2 seconds (just like in trunking), so to scan a dozen P25 conventional frequencies in OFT systems would take around 24 seconds and that's ridiculous.

Or am I doing something wrong????

 

[werinshades]

An agency in my area uses many (way over a dozen) conventional P25 frequencies so I added all of them to an OFT "system" to take advantage of radio ID capturing. This was my first time to have multiple frequencies in an OFT system and it sucks. I didn't realize you couldn't pick just one of those frequencies and park on it only. The only way to accomplish this is to have each frequency in its own system. Seeing how even with the system hold time set to zero the scanner still stays on each system for around 2 seconds (just like in trunking), so to scan a dozen P25 conventional frequencies in OFT systems would take around 24 seconds and that's ridiculous.

Or am I doing something wrong????

You can add all the frequencies on one site, or add multiple sites under a OFT. Unfortunately, as you know this is still slower than scanning conventionally, and having the text tagging option available.

 

[KevinC]

You can add all the frequencies on one site, or add multiple sites under a OFT. Unfortunately, as you know this is still slower than scanning conventionally, and having the text tagging option available.

Ah! Make each frequency its own site, is that correct? I wonder how long it dwells on each site? Is that 2 seconds also?

 

[werinshades]

Ah! Make each frequency its own site, is that correct? I wonder how long it dwells on each site? Is that 2 seconds also?

Yes, correct and I believe it's 2 seconds each.

You can number each site if you need to turn them on or off quickly, or affiliate each site with a department. If police use 1, correspond the Site number to the the police department.

 

[KevinC]

Yes, correct and I believe it's 2 seconds each.

So I’m still 24 seconds for a dozen frequencies. Unacceptable.

 

[werinshades]

So I’m still 24 seconds for a dozen frequencies. Unacceptable.

Yes, I agree. I also notice it "skips" over active OFT programmed systems, where in conventional programming it behaves correctly and stops consistently on active transmissions.

 

[KevinC]

Just tried multiple sites in trunking and it’s a little over one second per site, so this would be over 12 seconds. Still unacceptable.

 

[werinshades]

Just tried multiple sites in trunking and it’s a little over one second per site, so this would be over 12 seconds. Still unacceptable.

As I posted previously, eliminating OFT and allowing users the same option in Conventional Trunking system would be the optimal solution. If simplifying the scanners based on the upcoming new scanner releases is the goal, this would fall in line with that. Many here are confused about how to set up OFT systems, and by making the options only conventional or trunking, it would allow those that want to have additional information displayed in conventionally programmed digital system as they would in OFT could open up some options.

System Type: Conventional/Trunking

Audio Option:

Conventional Analog
Conventional DMR (Color Code/Slot Any/Slot 1/Slot 2)
Conventional NXDN (RAN/TGID)
(Unit ID w/Name Tab be added)

Trunking P25
Trunking MotoTRBO
Trunking NXDN

Imagine a world where scanner programming would be simplified.

 

[Ubbe]

Just tried multiple sites in trunking and it’s a little over one second per site, so this would be over 12 seconds. Still unacceptable.

It only dwells or waits on a frequency if it detects that it has a carrier, either the frequency are active with some kind of transmission or your squelch are set too low. If the squelch doesn't react it scans OFT systems at a rate of more than 45ch/s.

When it detects that the squelch has opened it always waits a minimum of 1,5 sec regardless if you have the hold time set to 0 or 1, this is set so that it has time to properly fully decode a digital signal, and can be set longer if it is a tricky simulcast system that are being monitored with a non simulcast scanner. In some cases if false decodes and thinks it's an encrypted signal and immediately continues scan and ignores the hold or delay timer.

I always use one frequency per site in an OFT system so that I can name that site with a name that make sense to me, and I can then also make a hold on that site.

/Ubbe

 

[werinshades]

It only dwells or waits on a frequency if it detects that it has a carrier, either the frequency are active with some kind of transmission or your squelch are set too low.



/Ubbe

No, it doesn't always behave this way which is what many have described. To prove this to myself, I set up a conventional P25 system in one SDS200 as OFT, and another I set it up as conventional. I'm close to the department so signal strength is not an issue. Scanning 3 analog systems on both scanners, with the OFT being the 4th on the one scanner. On numerous occasions, the conventional programmed P25 system will break squelch and receive transmissions while the OFT programmed scanner "skips" right over and catches the back end of a transmission. No encryption involved.

I've tried this on other conventional P25,DMR and NXDN systems over the years so this isn't a "new" issue, and always end up programming as a conventional system, and missing the added features of OFT programming to monitor the traffic correctly.

You mentioned something before, and the more I think about it makes sense. Since the scanner is "programmed as a trunking system", the scanner might be looking for a "control/rest" data burst in order to stop briefly enough to detect a signal, and when programmed as a conventional channel, it stops when it detects a "voice transmission" as scanners have been doing for eternity. The OFT programming structure is not as dependent as conventional programming.

 

[sonm10]

Yes, correct and I believe it's 2 seconds each.

So I’m still 24 seconds for a dozen frequencies. Unacceptable.

What are you guys talking about??? I don't have conventional P25, but do have conventional DMR (mainly schools and farmers) but when programmed as OFT, it scans just as fast as any other conventional object. I would seriously check Hold time, which should be 0. (and this is true on a SDS200 and BCD996P2)

 

[werinshades]

I would seriously check Hold time, which should be 0.

We seriously know what we're doing...totally!

 

[Ubbe]

The OFT programming structure is not as dependent as conventional programming.

Yes, I agree. All trunked decoding, at least DMR as I don't have any trunked P25, are unreliable and will occasionally skip calls. Conventional scanning are controlled and forced by the squelch detect so it stays on a frequency as long as there's a carrier, so scan control ignores what anomalies that the digital decoder have.

/Ubbe

 

[JoeBearcat]

Just tried multiple sites in trunking and it’s a little over one second per site, so this would be over 12 seconds. Still unacceptable.

It takes tome to evaluate data. We all wish the scanner could 'just know' what TGs are active.

Some people wanted the feature, so it was added. Now it's 'not good enough'.

If you have a lot of trunked systems, you will have to wait. As has been said here many times - the more you scan the less you hear. That is especially true when you have to evaluate a second of data. You just can't do that in half the time.

 

[GTR8000]

It takes tome to evaluate data. We all wish the scanner could 'just know' what TGs are active.

Some people wanted the feature, so it was added. Now it's 'not good enough'.

If you have a lot of trunked systems, you will have to wait. As has been said here many times - the more you scan the less you hear. That is especially true when you have to evaluate a second of data. You just can't do that in half the time.

Sounds like you're replying to someone who is talking about scanning actual trunked systems/control channels. In fact, the discussion is about the delay in scanning conventional channels using the hacky One Frequency Trunk "solution". Apples and oranges; there is no "data" to evaluate when a conventional channel has no carrier. 🤦‍♂️

 

[JoeBearcat]

Joe, please document the feature. In a conventional mode. When programming a DMR repeater/simplex, display tgid,uid ,ts. In p25 conventional tgid, uid. ! Many years have passed. Many people ask for this. DMR oft and p25 oft work very poorly.

OFT mode was the solution to people wanting to see this info. It's not a perfect solution, but nothing is short of time crunching where you gain 1 second of data in less time. I don't know if the engineers are that good.

I will ask if the OFT channel requires that full second or if evaluating it for a shorter period of time would miss some data. IOW, if it can be done faster I will request that.

 

[JoeBearcat]

Sounds like you're replying to someone who is talking about scanning actual trunked systems/control channels. In fact, the discussion is about the delay in scanning conventional channels using the hacky One Frequency Trunk "solution". Apples and oranges; there is no "data" to evaluate when a conventional channel has no carrier. 🤦‍♂️

If there is no carrier (data) it should fly by. (as noted above)

 

[GTR8000]

Okay. Except that it's not, so something is presumably broken with OFT. Let's call OFT what it is, a pig, a very inelegant "solution" to a problem that GRE models never had. Perhaps GRE had a patent for something that Uniden could not find a loophole for, and so direct decoding of P25 low speed data on the carrier (i.e. RID/TGID) could not be accomplished on a conventional channel, thus OFT was born. Or maybe it was just a case of over-engineering something that should've been straightforward.

Anyway, here we are. Instead of considering rethinking how Uniden scanners handle conventional digital decoding, we're talking about trying to shave seconds off of the time it takes to determine if there is a carrier in an OFT system, and if not, to resume scanning quickly instead of taking an awful amount of time to cycle through a mere 12 conventional frequencies. Yuck.

 

[JoeBearcat]

OK. If it's not working as intended I will pass that on. Your squelch is not open, correct?

 

[werinshades]

It's not broken, as much as it needs to be eliminated and users should be able to program conventional digital systems with all the same parameters as OFT. While OFT might allow you to text tag RID's (UID's), this should be able to be accomplished when programmed as a conventional digital channel. If a field is populated in the SDS display (not sure on other models), to see UID's (no name), it will show the number minus the text tag which tells me radio ID's do have a way to be seen in conventional digital mode, just can't text tag them. In addition if the system is programmed as OFT, you can't designate a Priority channel like I can when I have it programmed as digital conventional and use Priority DND. This would also require Sentinel updates to allow these programing changes. I know there is alot of work being put in on the waterfall option, but for most here, we prefer performance improvements first.