I curious as to how you found this out. Was this from computer data, first/second hand knowledge, or just monitoring the talk groups? I'm trying to keep up with the changes in the local area.
I don't know how daniel18522 monitors but I use SDRTrunk. When a talkgroup comes in encrypted, my display shows it (says encrypted) I haven't noticed it with Fremont but I was curious if he saw a TAC channel was encrypted (not unusual) or if one or more of their dispatch channels were encrypted.
Was listening to ALCO Comm 1 TG 5023.
Hayward Fire talkgroup lineup has changed:
ACFD Command 13 is now HAY CMD
ACFD Command 14 is now HAY TAC1
ACFD Tac 33 is now HAY TAC2
ACFD Tac 34 is now HAY TAC3
ACFD Tac 53 is now HAY TAC4
ACFD Tac 54 is now HAY TAC5
I also moved the Albany, Berkeley, and Piedmont fire talkgroups from Alameda County Fire to their respective cities, since they are not dispatched by ACRECC.
ACFD Command 13 is now HAY CMD
ACFD Command 14 is now HAY TAC1
ACFD Tac 33 is now HAY TAC2
ACFD Tac 34 is now HAY TAC3
ACFD Tac 53 is now HAY TAC4
ACFD Tac 54 is now HAY TAC5
I also moved the Albany, Berkeley, and Piedmont fire talkgroups from Alameda County Fire to their respective cities, since they are not dispatched by ACRECC.
Last edited:
What do people think about marking all TGs on the system as T (TDMA capable)? I believe everything is operating in dynamic dual mode now.
I agree.
I like to know which TGs are NOT TDMA because they can be monitored with a Phase I scanner (such as PSR-500).
I definitely understand that (which is why I haven't made the change already), but from a database standpoint T indicates TDMA-capable. D indicates that a talkgroup is FDMA-only, not capable of TDMA. So if the entire system is operating in dynamic dual mode (which I'm pretty sure it is), then all talkgroups should be marked T.
Currently, only talkgroups which have been actually seen in TDMA mode have been marked T, but there are certainly many talkgroups which are TDMA capable that we just haven't seen active yet. Conversely, there are some talkgroups marked T based on information from people with inside knowledge that the talkgroups are TDMA-capable, even though they may currently be operating in FDMA mode.
The bottom line is that any talkgroup currently operating in FDMA mode could switch to TDMA at any time, and vice versa (that's the nature of dynamic dual mode). Yes, it's nice to see which talkgroups are "usually" T or D, but I think marking them all T is a more accurate reflection of the state of the system.
Currently, only talkgroups which have been actually seen in TDMA mode have been marked T, but there are certainly many talkgroups which are TDMA capable that we just haven't seen active yet. Conversely, there are some talkgroups marked T based on information from people with inside knowledge that the talkgroups are TDMA-capable, even though they may currently be operating in FDMA mode.
The bottom line is that any talkgroup currently operating in FDMA mode could switch to TDMA at any time, and vice versa (that's the nature of dynamic dual mode). Yes, it's nice to see which talkgroups are "usually" T or D, but I think marking them all T is a more accurate reflection of the state of the system.
So I see a system with the following:
it indicates that it is unlikely to be monitored by a Phase I only receiver.
Then I see TGs marked with D and I know I can get them. If they're all marked with T, they can't. It's a BIG DEAL to me.
it indicates that it is unlikely to be monitored by a Phase I only receiver.
Then I see TGs marked with D and I know I can get them. If they're all marked with T, they can't. It's a BIG DEAL to me.
N6ML
Member
- Joined
- Sep 26, 2008
- Messages
- 1,284
I can see both sides of this one...
On one hand, I think it's of more practical value to the typical RR user if the database reflects what's actually been observed, rather than what's
theoretically possible. "Do I stand a chance of being able to hear this TG on my old scanner?" Even if a TG is not currently in dynamic dual mode, that, too, could change at any time...(?)
On the other hand, perhaps there's a scenario where a TG operates TDMA most of the time, but there's still that one guy who hasn't picked up his new radio yet, and when he's on shift, it goes back to FDMA. This could be confusing for a casual listener (with an old scanner) - "I wasn't able to hear this TG this morning, but now I can - WTF?"
Perhaps ideally the database should make the distinction - perhaps little-`t` for TDMA-capable and big-`T` for TDMA-in-use (like e/E for encryption)...
On one hand, I think it's of more practical value to the typical RR user if the database reflects what's actually been observed, rather than what's
theoretically possible. "Do I stand a chance of being able to hear this TG on my old scanner?" Even if a TG is not currently in dynamic dual mode, that, too, could change at any time...(?)
On the other hand, perhaps there's a scenario where a TG operates TDMA most of the time, but there's still that one guy who hasn't picked up his new radio yet, and when he's on shift, it goes back to FDMA. This could be confusing for a casual listener (with an old scanner) - "I wasn't able to hear this TG this morning, but now I can - WTF?"
Perhaps ideally the database should make the distinction - perhaps little-`t` for TDMA-capable and big-`T` for TDMA-in-use (like e/E for encryption)...
I don't even want to open up that can of worms haha. There are systems where I know the encryption is user-selectable, but it's used 99% of the time. Do we mark it E or e? If we mark it E, someone might look at it and say "oh, I won't be able to hear anything there" even though there is occasional traffic in the clear. If we mark it e, someone might think there's some traffic in the clear, and then be disappointed when it's so sparse. I generally lean toward E for strapped encryption and e for user-selectable encryption.
Back to T versus t for TDMA, again I see both sides of it so I'm not in a hurry to change it. I just wanted to start the conversation and see what people think. From a database standpoint since T means TDMA-capable, so I would lean toward T for dynamic dual mode talkgroups.
If it is not 100% E then it should be marked e, sparse or not.
Yeah this is a can of worms that will create more work for DB admins. In the spirit of how things have been, part-time TDMA should be t. You can see my tagline which shows I have several generations of receivers. The present method of marking TGs provides the info I need to determine what can be programmed into what receivers. I am very OK with leaving D for "part-time TDMA" but not OK with marking something T that is (only part-time TDMA).
ALCO fire dispatch has gone to phase 2. This change must have been made overnight as my 996XT was suddenly silent this morning but was able to confirm with my Whistler TRX-1 that they are indeed on phase 2. Hayward FD still phase 1.
Thanks, DB updated.
Hayward Fire Update. Have noticed testing on their Tac 4, TG 2713, for automated dispatch (that computer voice). A few months back it was for station 6 only, now it seems to have gone systemwide. However, they are still dispatching the old fashion way on HAY Fire Dispatch, TG 2255.
That's similar to what SFFD was doing last time I checked. Human dispatcher on A1/A2/A3 and robo dispatcher on another TG (932 I think).
I have been monitoring the com techs TG these past several months and have noted that Fremont PD, Union City PD and Newark PD all have had their radios encrypted. I don't know if the whole county will go encrypted at once or if it will be a department by department change. The last I heard not all cities were required by EBRCS to switch to encryption, but their dispatch consoles were upgraded in case they decided to. If anyone knows more, I'd appreciate the info.
The last update I heard is like what you’re hearing. Most cities are in the process of setting up encryption support across the board but still deciding if they wanted to go encrypted on their TGs. I know personally Berkeley PD was still on the fence if they wanted to go fully encrypted, but I have not heard an update in a few months.
If you monitor the board meeting notes, I know ACSO was mentioned briefly as pretty much a yes on encryption. (I will see if I can go find and cite the exact meeting I saw that in).
If you monitor the board meeting notes, I know ACSO was mentioned briefly as pretty much a yes on encryption. (I will see if I can go find and cite the exact meeting I saw that in).
I checked the board meeting notes last week and didn't see anything relevant. They have talked about getting a list of cities together that are going encrypted but that list has not been presented to any board meeting that I have seen.
Similar threads
