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

[werinshades]

Since firmware upgrades/improvements are being touched upon again, has there been any thoughts to eliminating the OFT programming structure, and allowing conventional digital with slots (DMR/NXDN) and Unit ID w/name (Unit ID/no name does show up) to replace it in both Sentinel and via firmware updates? You can program as I mentioned, but lose the ability to see the text tags of Unit ID's (Radio ID's), and appears to be the only difference. NAC/RAN is also programmable in a conventional system if P25/DMR/NXDN is chosen under the Audio Option tab. If the Unit ID/name tab is created under the conventional options, and under the display (SDS series), Unit ID/name is added in an available place setting, the OFT programming structure would not be necessary. Many here lose the benefit of OFT type programming, because of general confusion as to how to set it up. If the choices were Conventional or Trunking for a system, it might make it easier for everyone to take advantage if they wanted to do so.

I've been noticing on one of my local police departments since they switched from a statewide trunking to a conventional P25, I was missing transmissions unlike when they were using the statewide trunking system. I ruled out all the reception issues, filters etc, but noticed when it's scanning, the analog conventional systems I have programmed, would show scanning consistently, unlike the P25 OFT system. This was confirmed when their was no activity on the scanner itself, and was catching "back end" conversations (10-4, show me enroute etc.) Last night, I decided to experiment a bit and set it up as a P25 conventional system and conversations are in their entirety. I had a few other OFT trunking systems (P25/DMR) that I also experimented with and had the same results.

I don't know if Unit ID's show up on the x36hp or Home Patrol series in Conventional P25/DMR/NXDN programming? It could be an option for those that want to use it, and could eliminate the OFT programming confusion I've seen mentioned in these forums over the years.

 

[RoninJoliet]

Unit IDs do not show up on Uniden 996P2 on Conventional P25/DMR/NXDN programming only on trunking, just general info, but you can change the mode and see the CC , Slot or type of system in conv only.....

 

[werinshades]

Unit IDs do not show up on Uniden 996P2 on Conventional P25/DMR/NXDN programming only on trunking, just general info, but you can change the mode and see the CC , Slot or type of system in conv only.....

I know the scanners prior to the Home Patrol have a different programming structure that I'm not sure has the same flexibility as the later models. But, if it could, that would be a plus as well.

 

[JoeBearcat]

So you want OFT eliminated, then added in again?

What you are asking for is the reason OFT exists.

 

[werinshades]

So you want OFT eliminated, then added in again?

What you are asking for is the reason OFT exists.

I'm not sure how you came up with that analogy. If it was the same, then since I just reprogrammed the same frequency as a conventional P25, then I should be able to text tag the radio ID's or copy and paste my OFT programming radio ID's into a conventional system and see the same results which isn't the case. What you can see is the radio ID, but unable to label the radio ID's. That seems to be the only difference between OFT and conventional programming.

 

[JoeBearcat]

OFT adds access to other features as well.

Again, OFT was added to allow these features to be used on otherwise conventional frequencies.

Aside from having to program the frequency as OFT rather than in a conventional channel, why is OFT not a solution for what you want?

 

[werinshades]

OFT adds access to other features as well.

Again, OFT was added to allow these features to be used on otherwise conventional frequencies.

Aside from having to program the frequency as OFT rather than in a conventional channel, why is OFT not a solution for what you want?

What features (besides UID w/name & Slot) is not accessible with programming a non-trunking digital frequency (P25/DMR/NXDN) in conventional mode? NAC/Color Code/RAN is all programmable currently. If you choose DMR under Audio Option, a new field could be populated to add a Slot in case 2 slots are being used on the same frequency? Under the system Option tab, Unit ID can be added. The user would then have a choice of P25 Trunk, MotoTRBO Trunk/NXDN Trunk/Conventional when setting up a new system. Under the conventional system, the channel text tag/frequency/audio option(DMR-Slot when chosen...Any/Slot 1/Slot 2). Not bad huh?

 

[Ubbe]

the analog conventional systems I have programmed, would show scanning consistently, unlike the P25 OFT system. This was confirmed when their was no activity on the scanner itself, and was catching "back end" conversations

Unidens trunked decoding have some kind of bug that makes it unreliable and sometimes skips calls that conventional do not do when it has a longer time to sync to the data. Joebearcat mentioned that a new improved decoding are done to new firmware that seems to include all scanner models. So hopefully your digital decoding problem, and everybody else, will automatically be solved with the next firmware upgrade.

/Ubbe

 

[werinshades]

Unidens trunked decoding have some kind of bug that makes it unreliable and sometimes skips calls that conventional do not do when it has a longer time to sync to the data.

/Ubbe

Since OFT programming is not transmitting a data signal, not sure how a firmware update could help this scenario? Having the option to program a non-trunking digital system as conventional and adding the "missing features" I mentioned would be the optimal solution.

 

[Ubbe]

Since OFT programming is not transmitting a data signal, not sure how a firmware update could help this scenario? Having the option to program a non-trunking digital system as conventional and adding the "missing features" I mentioned would be the optimal solution.

But if there's no data signal then a conventional channel are skipped in 20mS. It needs to be a carrier that generates a squelch detect. For a conventional channel it stops scan on a carrier and then waits until the carrier are gone and starts the delay timer and then continues scan. If it detects a data signal it tries to decode it, if mode are set to All, and if it's encrypted it immediately skips the channel and starts scan.

For OFT it stops on the carrier but only have a limited time to successfully decode the data signal. If the that time runs out or if it thinks it is encryption it will start to scan. I believe that it is the false detect of encryption, or RAS, that are the culprit. If it thinks that it is a system using RAS it will abandon error correction and bit error rate goes up and it can more easily do a false detect of encryption. I hope that a new firmware upgrade have sorted this out, as the problem started when RAS compatibility where introduced in Unidens scanners.

/Ubbe

 

[werinshades]

But if there's no data signal then a conventional channel are skipped in 20mS. It needs to be a carrier that generates a squelch detect. For a conventional channel it stops scan on a carrier and then waits until the carrier are gone and starts the delay timer and then continues scan. If it detects a data signal it tries to decode it, if mode are set to All, and if it's encrypted it immediately skips the channel and starts scan.
/Ubbe

In a conventional scan of a digital frequency, it behaves like an analog scanning of a frequency. If it detects a signal, whether it's analog of conventional, it stops, produces a signal and moves on. The difference that I have seen is it actually "checks" the digital conventional frequency for activity, unlike the OFT programming where it's not consistently scanning because it might be looking for "data" since the system type is OFT.

I have it programmed both ways (not scanning at the same time), and can see and hear the difference in scanning and transmissions are consistent. I do have a couple of analog systems scanning too and as I mentioned, I can watch the display it's not consistently checking the OFT system. The only reason I leave it as OFT is because I can see the radio ID's. Depending on what's going on, I switch back and forth so nothing is missed.

The differences I can see are Unit ID w/name are not allowed. A field can be added via the display to show Unit ID's, but if the field is changed to Unit ID w/name, radio ID's are not seen. The other "option" is DMR Conventional that OFT has is you can program 2 slots (with or without the same talkgroup ID) on one frequency. Looking at Sentinel, under Audio Option, DMR Color Code can be programmed, but not the specific slot, which can also be changed. By eliminating the OFT programming feature, allowing the options mentioned, would resolve all of this and avoid programming confusion for some.

 

[Ubbe]

The difference that I have seen is it actually "checks" the digital conventional frequency for activity, unlike the OFT programming where it's not consistently scanning because it might be looking for "data" since the system type is OFT.

Conventional goes by the carrier detect. If it detects the idle bursts from a DMR cap+ system it will permanently stop on that channel if the delay time set are longer than the time between bursts. When the carrier drops long enough between bursts, or a conventional system completely drops its carrier, it will continue scan after the delay time runs out.

For OFT it uses the hold time if it detects a carrier with data and will always be a minimum of 1,5sec even if you set it to 1sec or 0, but will only stay something like 250mS on the frequency when not successfully decoding some valid data. You can check that by scanning with the squelch set to 0. When decoding data and if that data says that there is no active ongoing conversation it will continue scan after the hold time runs out. So it will continue scan even if it detects a DMR idle bursts or the system just outputs data messages that doesn't say that a TG are active.

When scanning in OFT mode and there's no carrier detected, it could be between the idle bursts, it scans through it in the usual scan time of 45ch/s for SDS scanners or 85ch/s for other scanners. The logic are that if there's no carrier then there can't be any data that needs to be decoded.

If you want it to work like in conventional but with the additional features of OFT it would be easier to instead add a delay time for OFT, in addition to hold, that always will stay on the frequency for that time regardless if there's no carrier detected from it. It's probably something for the wish list to add a selection of delay 1-10sec or 0 for no delay to get the current mode of operation. Probably a 5 minute change to the firmware and Sentinel. Perhaps if that added mode existed it would be used and appreciated by more users but up till now there haven't been much discussions about it.

/Ubbe

 

[werinshades]

Conventional goes by the carrier detect. If it detects the idle bursts from a DMR cap+ system it will permanently stop on that channel if the delay time set are longer than the time between bursts. When the carrier drops long enough between bursts, or a conventional system completely drops its carrier, it will continue scan after the delay time runs out.

For OFT it uses the hold time if it detects a carrier with data and will always be a minimum of 1,5sec even if you set it to 1sec or 0, but will only stay something like 250mS on the frequency when not successfully decoding some valid data. You can check that by scanning with the squelch set to 0. When decoding data and if that data says that there is no active ongoing conversation it will continue scan after the hold time runs out. So it will continue scan even if it detects a DMR idle bursts or the system just outputs data messages that doesn't say that a TG are active.

When scanning in OFT mode and there's no carrier detected, it could be between the idle bursts, it scans through it in the usual scan time of 45ch/s for SDS scanners or 85ch/s for other scanners. The logic are that if there's no carrier then there can't be any data that needs to be decoded.

If you want it to work like in conventional but with the additional features of OFT it would be easier to instead add a delay time for OFT, in addition to hold, that always will stay on the frequency for that time regardless if there's no carrier detected from it. It's probably something for the wish list to add a selection of delay 1-10sec or 0 for no delay to get the current mode of operation. Probably a 5 minute change to the firmware and Sentinel. Perhaps if that added mode existed it would be used and appreciated by more users but up till now there haven't been much discussions about it.

/Ubbe

If a digital frequency is conventional, it does not produce data bursts like a frequency being used in a trunking system. As you're describing, when programmed as a One Frequency Trunk (OFT), it is looking for that data burst that's not going to happen. You're also describing an even better reason to eliminate the OFT programming structure as it will not be as effective as programming a conventional digital system as conventional.

My OFT has been set up with a 2 second hold already, so that isn't the solution.

 

[sonm10]

If a digital frequency is conventional, it does not produce data bursts like a frequency being used in a trunking system. As you're describing, when programmed as a One Frequency Trunk (OFT), it is looking for that data burst that's not going to happen. You're also describing an even better reason to eliminate the OFT programming structure as it will not be as effective as programming a conventional digital system as conventional.

My OFT has been set up with a 2 second hold already, so that isn't the solution.

Not true. I've seen base stations send out idle data every minute.

 

[werinshades]

Not true. I've seen base stations send out idle data every minute.

Not if it's a P25 conventional system. If a data burst was being sent out, then it would "hang up" and stop on the frequency while in conventional scanning. If it's a DMR Conventional system, you might be seeing another MotoTRBO systems rest channel Data bursts within range.

 

[mikewazowski]

Not if it's a P25 conventional system. If a data burst was being sent out, then it would "hang up" and stop on the frequency while in conventional scanning. If it's a DMR Conventional system, you might be seeing another MotoTRBO systems rest channel Data bursts within range.

P25 and DMR conventional repeaters can both send out data bursts for a variety of reasons. That's why Uniden's implementation of DMR and P25 is extremely poor.

 

[werinshades]

P25 and DMR conventional repeaters can both send out data bursts for a variety of reasons. That's why Uniden's implementation of DMR and P25 is extremely poor.

In all of my local Conventional digital systems here, I can't remember ever having seen that. On a DMR Conventional, where both slots can be used, it could be possible, but probably not the best usage for capacity. On a P25 Conventional system, if any data is coming in, I would suspect it to be from another local source. In my scenarios, none of that applies.

 

[KevinC]

P25 and DMR conventional repeaters can both send out data bursts for a variety of reasons. That's why Uniden's implementation of DMR and P25 is extremely poor.

Common around here on DMR is one TS is used for location updates. So unless you use that goofy OFT your scanner can lock up on the data only TS and never leave.

Just let us program it like Whistler (which just happens to be how real radios are programmed).

 

[mikewazowski]

Common around here on DMR is one TS is used for location updates. So unless you use that goofy OFT your scanner can lock up on the data only TS and never leave.

That's what makes it hard to travel with a Uniden scanner. The GPS location feature is great but ignoring the slot, group and colour code information in the database makes it useless.

Just let us program it like Whistler (which just happens to be how real radios are programmed).

Yup.

 

[werinshades]

Common around here on DMR is one TS is used for location updates. So unless you use that goofy OFT your scanner can lock up on the data only TS and never leave.

Just let us program it like Whistler (which just happens to be how real radios are programmed).

Yes...under Audio Option...DMR Conventional...allow Color Code/Slot to be programmed.

Does NXDN Conventional use different slots? If so, same option could be added.