Help me help you

[werinshades]

Before getting too excited, does doing a site or system hold work? Or does the scanner still miss traffic? If it still misses traffic programmed OFT with a zero Delay and a system or site hold active, there is a firmware bug that needs to be fixed.

If you're asking me, no it doesn't. Both Talkgroup ID's are being transmitted on the same frequency (Maybe I didn't make that clear). TGID 1 is the Mobile..TGID 65535 is Dispatch. System Hold makes no difference. If Engine A transmits, "we're on the scene...etc", Dispatch's reply might be heard if the transmission is long enough and is caught when the scanner comes back to it. In Conventional mode, this isn't the issue, but the Radio ID's can be seen, but not allowed to be edited.

Set it to Site Hold, shouldn't matter if you only have one site in the system, and TG delay to 0 sec. It should work fine in that mode. And this is on a 996 scanner as SDS scanners can be easily compromised by some interference issue?

You can't use that method for normal scanner use but it should prove that nothing else are going on. In your situation you would need to have the conventional scanning being enhanced as you have suggested.

In many duplex systems the audio from RX are not repeated out on TX to minimize the chatter and the annoyance of mobile users having too much modulation. Often used with taxi cab channels and other non critical operations where one mobile user only needs help from the dispatcher and not other mobile users. It seems like they have programmed this system to mimic that. Perhaps they can patch the two TG's together if the need should arise in an emergency situation, as they often can do in duplex repeaters by pushing a button to get full repeater audio.

/Ubbe

All suggestions have been previously tried...conventional P25 with UID Name would be the ideal resolution.

 

[ka3jjz]

I don't know if anyone at Uniden is watching this, but the TWiki has been down since Saturday....Mike

 

[jonwienke]

That’s one way to do it I guess.

Don't get too hung up on the "one frequency" thing. A OFT system can have multiple talkgroups, multiple departments, multiple sites, and multiple frequencies programmed for each site, and will work just fine.

If you have a common group of users on a collection of repeaters, and the UID and talkgroup ID usage is consistent for each repeater, then programming a single OFT system with a single set of talkgroups, departments, and UIDs, and a separate site for each repeater makes the most sense.

 

[jonwienke]

All suggestions have been previously tried...conventional P25 with UID Name would be the ideal resolution.

No. Fixing the bug in OFT so that a zero delay actually works as a zero delay when you have an active site hold is the ideal resolution. The OFT data structure is the only practical way to enable unit and talkgroup ID functions; adding that to conventional channels would essentially turn every conventional channel into a OFT system, with the attendant data bloat and most likely a performance hit.

 

[mikewazowski]

and the UID and talkgroup ID usage is consistent for each repeater, then programming a single OFT system with a single set of talkgroups, departments, and UIDs, and a separate site for each repeater makes the most sense.

Luckily for me the groups are not consistent and are unique to each department.

 

[werinshades]

No. Fixing the bug in OFT so that a zero delay actually works as a zero delay when you have an active site hold is the ideal resolution. The OFT data structure is the only practical way to enable unit and talkgroup ID functions; adding that to conventional channels would essentially turn every conventional channel into a OFT system, with the attendant data bloat and most likely a performance hit.

..as I've been saying, I have done all this, including a 0 talkgroup delay. As I've also said, elimination of OFT or an option to program a one frequency system and allow Unit ID's with name to be programmed would be the ideal solution in this case. I understand the entire OFT programming algorithm and use it on a few other systems. I do know what I'm doing Jon, and hope this request is taken into consideration by Uniden. So...to review...System Hold...0 talkgroup delay...2 separate talkgroups assigned to dispatch and mobiles... due to this, replies are being cut off or missed if they are short.."message received"...

 

[jonwienke]

No. The solution is to fix the problem with OFT, not turning conventional channels into a second redundant version of OFT.

 

[werinshades]

No. The solution is to fix the problem with OFT, not turning conventional channels into a second redundant version of OFT.

Are you speaking for Uniden now or just an opinion? I thought this thread's intent was for suggestions for improvements and not asking for individuals input as to whether they think someone's idea is approved by Jon Wienke? If you don't think it's a good idea..read it and move on. Joe Bearcat..hello..

 

[jonwienke]

Are you speaking for Uniden now or just an opinion? I thought this thread's intent was for suggestions for improvements and not asking for individuals input as to whether they think someone's idea is approved by Jon Wienke? If you don't think it's a good idea..read it and move on. Joe Bearcat..hello..

I'm speaking from 20+ years of experience in IT, specifically in programming and relational database design. What you're asking for is 100% absolutely guaranteed the wrong solution, and cannot be done practically. Here's why:

Conventional channels are programmed with a single data row per channel containing the frequency, CTCSS tone, digital format type, etc. But a single data row format cannot be used if you want UID and talkgroup functionality. You need a separate data row for each UID, and a separate set of data rows for each talkgroup ID. If you tried to add a UID field to the conventional channel data row definition, you immediately have 2 problems. First, you're limited to a fixed number of UIDs, because you have to explicitly define a separate column dedicated to each UID name and ID value. So if you add 100 UIDs to conventional channels, you have to add 200 columns to the conventional channel data row definition (id1, name1, id2, name2, etc). Second, and worse, you're forcing tbe addition of those data colums to EVERY conventional channel, even the majority that aren't digital, and don't even use user IDs. So that pointlessly bloats the conventional channel definition with 200 extra variables per conventional channel that have to be allocated memory, and that is guaranteed to bog down the scanner.

Worse, that doesn't even solve the problem if the system has more than 100 UIDs, so in that case, you've bloated the conventional data channel data structure into uselessness for nothing.

The correct, and the only scalable and practical solution to the problem, is to use the relational database paradigm to relate multiple sets of data rows together. Have one set of data rows for frequencies, another set for unit IDs, yet another for talkgroups, and define relationships between the frequency, UID, and talkgroup datasets to define the system instead of trying to make all of that data fit in a single fixed row. That makes memory allocation more efficient, because you aren't forced to allocate memory to store variables that aren't even used most of the time, and it's scalable, because the only limits to the number of frequencies, users, and talkgroups you can define for a system are imposed by available memory, not the number of columns defined in the conventional channel data row layout.

That is precisely what Uniden did in creating the OFT system data structure (separate data tables for frequencies, users, and talkgroups), and why what you're asking for is 100% absolutely the wrong way to solve the problem, would totally break conventional scanning, and still wouldn't do what you want if the system had more than the arbitrarily chosen fixed number of UIDs.

I don't work for Uniden, but I would feel comfortable betting a year's pay on your request being denied for those reasons.

 

[werinshades]

I'm speaking from 20+ years of experience in IT, specifically in programming and relational database design. What you're asking for is 100% absolutely guaranteed the wrong solution, and cannot be done practically. Here's why:

Conventional channels are programmed with a single data row per channel containing the frequency, CTCSS tone, digital format type, etc. But a single data row format cannot be used if you want UID and talkgroup functionality. You need a separate data row for each UID, and a separate set of data rows for each talkgroup ID. If you tried to add a UID field to the conventional channel data row definition, you immediately have 2 problems. First, you're limited to a fixed number of UIDs, because you have to explicitly define a separate column dedicated to each UID name and ID value. So if you add 100 UIDs to conventional channels, you have to add 200 columns to the conventional channel data row definition (id1, name1, id2, name2, etc). Second, and worse, you're forcing tbe addition of those data colums to EVERY conventional channel, even the majority that aren't digital, and don't even use user IDs. So that pointlessly bloats the conventional channel definition with 200 extra variables per conventional channel that have to be allocated memory, and that is guaranteed to bog down the scanner.

Worse, that doesn't even solve the problem if the system has more than 100 UIDs, so in that case, you've bloated the conventional data channel data structure into uselessness for nothing.

The correct, and the only scalable and practical solution to the problem, is to use the relational database paradigm to relate multiple sets of data rows together. Have one set of data rows for frequencies, another set for unit IDs, yet another for talkgroups, and define relationships between the frequency, UID, and talkgroup datasets to define the system instead of trying to make all of that data fit in a single fixed row. That makes memory allocation more efficient, because you aren't forced to allocate memory to store variables that aren't even used most of the time, and it's scalable, because the only limits to the number of frequencies, users, and talkgroups you can define for a system are imposed by available memory, not the number of columns defined in the conventional channel data row layout.

That is precisely what Uniden did in creating the OFT system data structure (separate data tables for frequencies, users, and talkgroups), and why what you're asking for is 100% absolutely the wrong way to solve the problem, would totally break conventional scanning, and still wouldn't do what you want if the system had more than the arbitrarily chosen fixed number of UIDs.

I don't work for Uniden, but I would feel comfortable betting a year's pay on your request being denied for those reasons.

This makes sense, and being this a very unique problem based on what I've been reading, it's too bad because I like and much prefer using the OFT programming to document the radio ID's. This is not a "new" system, and have tried using the OFT on different scanners over the years. All suggestions have been previously tried, and having the two separate talkgroups makes it challenging and nearly impossible to properly monitor it in OFT.

 

[Ubbe]

All suggestions have been previously tried, and having the two separate talkgroups makes it challenging and nearly impossible to properly monitor it in OFT.

One feature that could be added easily to OFT, and any trunked system, are a user selection per system to have a post-hold time that would be used after a conversation ends.

As it is now in trunked system as soon as a TG delay time runs out the whole system are exited and the scanner continous to scan to the next system. You cannot continue to monitor another TG in that system. You'll have to wait one full scan cycle to return to that system and then you are only able to monitor one TG conversation and it will continue to scan once again.

If having a post-hold timer, that could be set to zero to keep the current mode, you could have that set to 5 sec where it will wait for new calls, starting to tick after the TG delay timer have run out.

This is useful for systems where you wish to monitor as much as possible, almost like a priority type of function. Of course we want as many selectable options as possible so the best thing would be if each TG could have a flag to indicate if it should use post-hold or not. And of course we want the same configurable settings for IDscan TG's that we have for programmed TG's. Delay and alert&lights and also record and all that.

/Ubbe

 

[werinshades]

This is my 3 different ways it's programmed (I don't monitor all of them at once). Conventional is the primary mode of monitoring.

 

[ausscan]

@JoeBearcat - This is related to database structure.

In reprogramming my HHs in the last few weeks, to put the same department across two systems I need to enter & update them twice.

Would it not make more sense to have that department in there once, and refer to it in two systems, therefore eliminating the need to cross maintain? SD Card space is not an issue for me as I have 32gb cards in there and the systems take up next to no space.



Here is a RL example - bearing in mind that the Zip Code and Database is of no use outside of Northern America:

I have my statewide ESO system in a FL called "VRN"

In that FL, I have two (actually three but one is conventional) P25 systems, one containing the sites that I can RX from home, and the other with ones I RX when I am mobile, or ones that I can get on my home antenna. They typically only carry the talk groups for the services that operate on them, so if I want to hear anything outside my local radius I need to use other sites.

Doing it this way allows to me to lock in/out a system and lock out sites in one go that I don't get on the HH at home. This also means when I am out, I can lock the entire FL out so that I can focus on a particular system, for instance if I am DMR tracking.

For the VRN FL, I then need to manage two lists of TGIDs and two lists of UIDs. I also have 27 departments that cover 570 TGIDs, and I still don't have all the TGIDs in there. You can see where I am going with this.

I understand I can set sites by quick key - problem is with this, I forget which quick key is which and it is easier to lock out the whole system including the sites I don't need. If they could be switched on and off via the "Set Scan Selection" menu, this may work around this.

 

[ka3jjz]

Not to take this off track, but has anyone heard from Joe? I tried PM and got no reply. The TWiki (where the firmware fix links are stored) has been down since the weekend. Hopefully he's just gotten pulled to another project and isn't sick with COVID (or worse).....Mike

 

[donc13]

His profile here on RR shows he was last on April 14th

 

[snerd]

Probably on a week's R&R.

 

[Ronaldski]

He was on the scanner guys youtube yesterday in the comments section. So dont fret about it, just a busy fellow!

 

[ka3jjz]

Yeah I suspect he got yanked onto some other project. Hopefully he'll be back soon....Mike

 

[JoeBearcat]

Are you speaking for Uniden now or just an opinion? I thought this thread's intent was for suggestions for improvements and not asking for individuals input as to whether they think someone's idea is approved by Jon Wienke? If you don't think it's a good idea..read it and move on. Joe Bearcat..hello..

I agree with the concept that fixing a bug is better than introducing a new feature that addresses what the bug fix would solve.

 

[JoeBearcat]

I'm speaking from 20+ years of experience in IT, specifically in programming and relational database design. What you're asking for is 100% absolutely guaranteed the wrong solution, and cannot be done practically. Here's why:

Conventional channels are programmed with a single data row per channel containing the frequency, CTCSS tone, digital format type, etc. But a single data row format cannot be used if you want UID and talkgroup functionality. You need a separate data row for each UID, and a separate set of data rows for each talkgroup ID. If you tried to add a UID field to the conventional channel data row definition, you immediately have 2 problems. First, you're limited to a fixed number of UIDs, because you have to explicitly define a separate column dedicated to each UID name and ID value. So if you add 100 UIDs to conventional channels, you have to add 200 columns to the conventional channel data row definition (id1, name1, id2, name2, etc). Second, and worse, you're forcing tbe addition of those data colums to EVERY conventional channel, even the majority that aren't digital, and don't even use user IDs. So that pointlessly bloats the conventional channel definition with 200 extra variables per conventional channel that have to be allocated memory, and that is guaranteed to bog down the scanner.

Worse, that doesn't even solve the problem if the system has more than 100 UIDs, so in that case, you've bloated the conventional data channel data structure into uselessness for nothing.

The correct, and the only scalable and practical solution to the problem, is to use the relational database paradigm to relate multiple sets of data rows together. Have one set of data rows for frequencies, another set for unit IDs, yet another for talkgroups, and define relationships between the frequency, UID, and talkgroup datasets to define the system instead of trying to make all of that data fit in a single fixed row. That makes memory allocation more efficient, because you aren't forced to allocate memory to store variables that aren't even used most of the time, and it's scalable, because the only limits to the number of frequencies, users, and talkgroups you can define for a system are imposed by available memory, not the number of columns defined in the conventional channel data row layout.

That is precisely what Uniden did in creating the OFT system data structure (separate data tables for frequencies, users, and talkgroups),

That explanation is pretty much dead-on.