Tac a

[n1chu]

By that I understand any of the Interop TAC TG’s are what I refer to as Command & Control, with separate radio nets handling the numerous individual crews. It fits if what I’ve been able to hear in Farmington is any indication. What I hear is nothing much at all on the 1503 TG except for one transmission early yesterday morning. (I’ve added 1504 TG this morning and am listening to both TG’s to start with, then narrow down which sites I keep. But as for other radio caches being used my guess is it’s mostly all simplex. I’d have to be a lot closer than I am in order to hear anything. But I’ve been there done that (as I’ve previously mentioned as a DEP radio Comms dispatcher out of CO (Central Offices, state office building and a State of Ct. District Fire Warden). So I can pretty much guess at the communications organization structure and be 95% correct. Besides, they don’t need an old retread like me poking my nose in where it doesn’t belong.

However, I’ve been known to do some “hill topping”, far enough away where I am not a hinderance but close enough to hear what’s happening on my scanner. To that end, it would be nice if discovered frequencies used would be reported here. (For those who haven’t heard the term “hill topping”, it means driving up to the highest parts of the terrain where you can safely park and do some monitoring. Mohawk Mtn has a fire lookout tower which is no longer used but it’s also a state forest which allows visitors to park. Chippens Hill in Bristol is another area… I suppose everyone has their favorite spot.

 

[cg]

Interop groups/freqs are not limited to command and control, that is just a common use.
I would be monitoring ITAC/ICALL (STOCS) locally.
TG 1503 has been very busy from 0700-2000 or so each day with perhaps over 5000 hits logged since the start.

 

[n1chu]

Interop groups/freqs are not limited to command and control, that is just a common use.
I would be monitoring ITAC/ICALL (STOCS) locally.
TG 1503 has been very busy from 0700-2000 or so each day with perhaps over 5000 hits logged since the start.

All set. Thank you for the heads up. Apparently little fingers got curious sometime after I arrived home a couple of days ago and it never dawned on me why the scanner was so quiet! At least that’s what I suspect happened. But just to be sure, I’m going to do a little programming on the SDS200. I will also be sure to include the ITAC/CALL (STOCS) if I go hilltopping.

 

[n1chu]

Interop groups/freqs are not limited to command and control, that is just a common use.
I would be monitoring ITAC/ICALL (STOCS) locally.
TG 1503 has been very busy from 0700-2000 or so each day with perhaps over 5000 hits logged since the start.

I just used the C & C as an example to differentiate between the groups identified. And the reprogramming worked nicely. TAC A is banging in. Now I just need to whittle down the sites… Site ID is 28. Hartford Troop H.

 

[coolrich55]

Tac B is also in use. In case that hasn't been mentioned yet.

 

[55engine]

Is that for the Franklin fire?

 

[n1chu]

I see 1503, 1504 and 1505 highlighted in RR… but I haven’t kept track which fires are using which TAC channels (with the exception of Interop Tac A, which is the Hawthorne Berlin Fire…).

 

[mbnv992]

I wondered what all those new radios were in 1503....8 or so new trooper portables

Gonna guess - APX NEXT ? They’ve had the 6000’s forever so I’m gonna assume they are getting all new NEXT radios ( unless they are ordering 8000’s now ? )

 

[adamfancher]

Radio ranges are not always only the main users, 180xxxx is mostly CSP but not all. There are many cache radios being used at the fire.
Here is an old pic of some CT USAR radios on one of their vehicles back in 2016. CTS has many more than this available.

View attachment 171497

Good to know! In reviewing the audio from the 180xxxx radios active in the TAC A talkgroup, I found this to be the case.
Those radios are now marked as Cache Radios (USAR for now)

 

[Kitn1mcc]

it says CT transit Portable. Maybe they went over to listen to whats going on

 

[srsanford]

I entered a few TG’s in anticipation of Avon coming on board. I used 10401, 10402, 10403, 10411 and 10412. I believe I got the right town tax code number and followed what Newington is using for their fire dispatch (19411). So far I’ve not heard anything for Avon. I sent out a few requests to the Deputy Chief in Avon (who is heading up the effort-he’s also a ham) but got zero replies. My guess is they aren’t close enough to assign the TG’s, so he has nothing to reply.

I have been monitoring the Avon talkgroup range (10400 - 10499) in SDRTrunk on the Troop H Simulcast Site this week. I've have seen some traffic on:

• 10411 - Possibly Avon PD, although its currently encrypted.
• 10421 - Likely Avon FD

Will keep checking the event history and recordings...

 

[n1chu]

I have been monitoring the Avon talkgroup range (10400 - 10499) in SDRTrunk on the Troop H Simulcast Site this week. I've have seen some traffic on:

• 10411 - Possibly Avon PD, although its currently encrypted.
• 10421 - Likely Avon FD

Will keep checking the event history and recordings...

Good to know. Thank you. I will keep checking back with the group and you for additional TG’s as they become active. I’d like to say I would also monitor the Avon PD on their current UHF frequency and compare to transmissions on the encrypted 10411 TG to determine if it is in fact the PD, (and not the service techs setting up the system) but I wonder if that’s possible with the Uniden SDS100/200… it’s my understanding these scanners ignore encryption and continue scanning. Maybe it I use an older scanner and monitor the control channels?

 

[cg]

off topic for TAC A, but I added the 7 TGs I identified for Avon to the SNE WIKI for CLMRN. go down to municipalities

Connecticut Land Mobile Radio Network - Scan New England Wiki

www.snewiki.com

I suspect 10401 is Avon ATG but not confirmed.
PD had been clear for some testing last month.
FD testing was likely on UHF and patched over as all traffic was showing External. I expect that the patches will come and go as testing proceeds

 

[n1chu]

I added the 7 TG’s you have identified as Avon’s.

A follow-on question… I believe I was previously referring to the term “site” incorrectly. At the time, it was my understanding a site was a single geographical point, as it relates to CLMRN, the specific location of where the system’s antennas were located. But, if I’ve got it right now, that is wrong. A site might consist of just the one location or include additional locations, all regarded as subsystems of the site? Working under this new understanding, I wondered about these subsystems. Are they both transmit and receive or just receive? (I expect they could be either, determined by what is needed.) And, I’m guessing they all use the same frequencies as listed for the site. And that’s where the simulcast issue comes into play, all the subsystems transmitting at the same time?

 

[W1KNE]

Think of a site like a cellular "cell". You can have one tower, or you can have multiple towers. It's a "simulcast cell". All towers will have all the same frequencies (output and inputs), and all carry the same traffic, at the same time, on the same frequency as each other. So all towers within the cell will transmit at the same time. All the transmitters are GPS carrier locked for reference and the system syncs up based on latency the delay, so that the audio is in perfect time as well. On a good receiver such as a Unication or SDS, or with a commercial radio, you can get almost nearly identical signals from multiple towers and never know it.

 

[n1chu]

Good info. So, essentially you are saying yes to my understanding of what a “site” consists of. I’ve understood the syncing (the reason non SDS receivers have problems) and the need to recognize latency. But I’ve always wondered how whoever came up with the idea to transmit the same signal, at the same time, off of more than one antenna in differing locations, ever got around the basic understanding that sort of thing doesn’t work! What was it that pulled the thought process that way instead of sending out a duplicate digital transmission sequentially instead of simultaneously? That would have eliminated the simulcast issue entirely. Or maybe they have that option available but don’t use it unless they learn the apparatus needed to run the system as it is currently set up starts to cause problems as it ages? -Just spitballing here…

 

[ems170]

Slightly off topic but to answer the question:

As the frequency spectrum is limited and the regulatory bodies want to achieve maximum spectrum efficiency, there is a need to cover a target area while reducing how far outside that target area the frequency extends. Where one time the thought process was put a really strong transmitter at the highest point and blast the ERP to meet coverage needs (think FDNY VHF channels on the top of skyscrapers), there were problems with this. First off, talk-out coverage is not automatically reflective of talk-in. Blasting a signal out of a single receiver does not help the portable that is at the furthest service area trying to reach the tower. Secondly, A high ERP based on power and elevation means that you can't use that frequency again for some distance. Remember RF will travel great distances based on the horizon and sometimes the ionosphere reflection depending on its properties. A high elevation improves the distance before the horizon blocks the signal, now think of user 2 who has another high tower blasting out the same frequency and you can see why this is not efficient.

This means that you can either blast out the signal from a single site and set up receiver sites to capture the system talk-in coverage, or you can use a simulcast system to achieve good talk-in and talk-out coverage in the desired area, while reducing the footprint outside of the needed coverage area due to lower ERP needs.

Sequential transmissions would be problematic because they are essentially acting as individual sites, so, not only would a single message take a lot of air time to be individually broadcast by the sites if they were asynchronous and on the same frequency (which would create interference and timing issues and need some form of buffering for the audio), but there would also be a need to have the user manually select the best site to TX and RX on. This technology was commonly used to gain "wide" area coverage before simulcast technology became as good as it did. Multi-cast systems would broadcast the same message over multiple sites, close to but asynchronously. The end user would generally pick the radio channel (site) that they felt would give them the best talk-in coverage (this is a quick summary so, yes there are voted scan and talkback options, that will be left off).

A properly engineered simulcast system will engineer its overlap points based again on the service area. This will typically attempt to put the points where signal strength timing will be most out of sync and/or equal signal strength from multiple towers over areas that are isolated or expected to have teh least impact on system users. The issues associated with simulcast distortion are mainly with hobby listeners. Quality receivers and mission-critical equipment does very well with simulcast signaling when properly tuned and programmed correctly. This means that the simulcast issues are not really issues as they have minimal impact on the people whom the system was designed for.

I hope that this extremely brief and incomplete post on system selection and design shows why places choose simulcast systems over traditional conventional or multi-cast systems.

 

[adamfancher]

Slightly off topic but to answer the question:

As the frequency spectrum is limited and the regulatory bodies want to achieve maximum spectrum efficiency, there is a need to cover a target area while reducing how far outside that target area the frequency extends. Where one time the thought process was put a really strong transmitter at the highest point and blast the ERP to meet coverage needs (think FDNY VHF channels on the top of skyscrapers), there were problems with this. First off, talk-out coverage is not automatically reflective of talk-in. Blasting a signal out of a single receiver does not help the portable that is at the furthest service area trying to reach the tower. Secondly, A high ERP based on power and elevation means that you can't use that frequency again for some distance. Remember RF will travel great distances based on the horizon and sometimes the ionosphere reflection depending on its properties. A high elevation improves the distance before the horizon blocks the signal, now think of user 2 who has another high tower blasting out the same frequency and you can see why this is not efficient.

This means that you can either blast out the signal from a single site and set up receiver sites to capture the system talk-in coverage, or you can use a simulcast system to achieve good talk-in and talk-out coverage in the desired area, while reducing the footprint outside of the needed coverage area due to lower ERP needs.

Sequential transmissions would be problematic because they are essentially acting as individual sites, so, not only would a single message take a lot of air time to be individually broadcast by the sites if they were asynchronous and on the same frequency (which would create interference and timing issues and need some form of buffering for the audio), but there would also be a need to have the user manually select the best site to TX and RX on. This technology was commonly used to gain "wide" area coverage before simulcast technology became as good as it did. Multi-cast systems would broadcast the same message over multiple sites, close to but asynchronously. The end user would generally pick the radio channel (site) that they felt would give them the best talk-in coverage (this is a quick summary so, yes there are voted scan and talkback options, that will be left off).

A properly engineered simulcast system will engineer its overlap points based again on the service area. This will typically attempt to put the points where signal strength timing will be most out of sync and/or equal signal strength from multiple towers over areas that are isolated or expected to have teh least impact on system users. The issues associated with simulcast distortion are mainly with hobby listeners. Quality receivers and mission-critical equipment does very well with simulcast signaling when properly tuned and programmed correctly. This means that the simulcast issues are not really issues as they have minimal impact on the people whom the system was designed for.

I hope that this extremely brief and incomplete post on system selection and design shows why places choose simulcast systems over traditional conventional or multi-cast systems.

Very informative. Thanks for sharing!

 

[n1chu]

Slightly off topic but to answer the question:

As the frequency spectrum is limited and the regulatory bodies want to achieve maximum spectrum efficiency, there is a need to cover a target area while reducing how far outside that target area the frequency extends. Where one time the thought process was put a really strong transmitter at the highest point and blast the ERP to meet coverage needs (think FDNY VHF channels on the top of skyscrapers), there were problems with this. First off, talk-out coverage is not automatically reflective of talk-in. Blasting a signal out of a single receiver does not help the portable that is at the furthest service area trying to reach the tower. Secondly, A high ERP based on power and elevation means that you can't use that frequency again for some distance. Remember RF will travel great distances based on the horizon and sometimes the ionosphere reflection depending on its properties. A high elevation improves the distance before the horizon blocks the signal, now think of user 2 who has another high tower blasting out the same frequency and you can see why this is not efficient.

This means that you can either blast out the signal from a single site and set up receiver sites to capture the system talk-in coverage, or you can use a simulcast system to achieve good talk-in and talk-out coverage in the desired area, while reducing the footprint outside of the needed coverage area due to lower ERP needs.

Sequential transmissions would be problematic because they are essentially acting as individual sites, so, not only would a single message take a lot of air time to be individually broadcast by the sites if they were asynchronous and on the same frequency (which would create interference and timing issues and need some form of buffering for the audio), but there would also be a need to have the user manually select the best site to TX and RX on. This technology was commonly used to gain "wide" area coverage before simulcast technology became as good as it did. Multi-cast systems would broadcast the same message over multiple sites, close to but asynchronously. The end user would generally pick the radio channel (site) that they felt would give them the best talk-in coverage (this is a quick summary so, yes there are voted scan and talkback options, that will be left off).

A properly engineered simulcast system will engineer its overlap points based again on the service area. This will typically attempt to put the points where signal strength timing will be most out of sync and/or equal signal strength from multiple towers over areas that are isolated or expected to have teh least impact on system users. The issues associated with simulcast distortion are mainly with hobby listeners. Quality receivers and mission-critical equipment does very well with simulcast signaling when properly tuned and programmed correctly. This means that the simulcast issues are not really issues as they have minimal impact on the people whom the system was designed for.

I hope that this extremely brief and incomplete post on system selection and design shows why places choose simulcast systems over traditional conventional or multi-cast systems.

 

[n1chu]

Your third paragraph (Sequential transmissions) is what I had asked about. Thank you for the explanation. I do wonder about separate transmissions taking up too much time or overlapping each other. If the transmissions are addressed with unique addresses for each transmission sites and in digital packet form, I wonder if taking too much time would be a factor worth considering… digital is fast. But I do agree with your take on simulcast issues being primarily a problem with hobbyists, as the commercial hardware offerings have mastered the art of simulcast. It just didn’t seem to be the logical path to take, simultanious requiring additional engineering and hardware. Thank you for the input. I’m obviously no expert on the subject and bow to your better understanding of the mode.