BCD325P2/BCD996P2: Simulcast distortion fix

[GTR8000]

But it does in relation to the talkgroup, and the authorization of that talkgroup on certain sites.

For different logical sites, yes, but not for different subsites within a simulcast cell. Since the topic of this thread is about simulcast distortion, that really isn't relevant to the discussion.

 

[900mhz]

I think you are talking about a multi-site system, which is a completely different animal than simulcast.

Yes, some talkgroups, while authorized for utilization within their simulcast cell, may not require such in an adjacent simulcast area

 

[900mhz]

For different logical sites, yes, but not for different subsites within a simulcast cell. Since the topic of this thread is about simulcast distortion, that really isn't relevant to the discussion.

reason I bring this up...perhaps you may experience simulcast distortion in one area, but switching to an adjacent may yield better results, especially if the adjacent site does not rely on affiliation, but is set up to handle (depending on the talkgroup) 24X7

 

[GTR8000]

reason I bring this up...perhaps you may experience simulcast distortion in one area, but switching to an adjacent may yield better results, especially if the adjacent site does not rely on affiliation, but is set up to handle (depending on the talkgroup) 24X7

Valid point. If someone is fortunate enough to be in range of a standalone site that carries the same traffic they're interested in, they can probably just avoid the simulcast cell.

 

[GTR8000]

I'm going to throw a bit of a wrench into this thread just for fun. In fact packet data is actually subsite steered whenever possible, rather than going out over every subsite in the simulcast cell like the voice traffic does. The system will broadcast the data over whichever subsite the subscriber last voted to. If that is unknown, then the data will go out over every subsite in the cell. This is done presumably because data doesn't play well with simulcast the same way voice traffic does.

Of course that has no bearing on a scanner receiving voice transmissions, but it is a tidbit for those who have interest in the nuts and bolts of these systems. I should say also that this applies to Motorola ASTRO 25 IV&D systems, I'm not sure if it applies to systems by other manufacturers.

 

[KevinC]

I'm going to throw a bit of a wrench into this thread just for fun. In fact packet data is actually subsite steered whenever possible, rather than going out over every subsite in the simulcast cell like the voice traffic does. The system will broadcast the data over whichever subsite the subscriber last voted to. If that is unknown, then the data will go out over every subsite in the cell. This is done presumably because data doesn't play well with simulcast the same way voice traffic does.

Of course that has no bearing on a scanner receiving voice transmissions, but it is a tidbit for those who have interest in the nuts and bolts of these systems. I should say also that this applies to Motorola ASTRO 25 IV&D systems, I'm not sure if it applies to systems by other manufacturers.

You're just making up crap now.

I should probably add this...

 

[slicerwizard]

The system will broadcast the data over whichever subsite the subscriber last voted to.

If the subscriber moves to another subsite's area, how would the system know?

This is done presumably because data doesn't play well with simulcast the same way voice traffic does.

Is this 9600 bps data? If so, the only difference should be the ramifications of unrecoverable packet data (message lost or retry required) vs the odd dropped audio frame.

 

[KevinC]

If the subscriber moves to another subsite's area, how would the system know?

Via uplink from the comparator.

 

[slicerwizard]

Via uplink from the comparator.

So before a packet data transmission, there is a handshake with the subscriber?

 

[n1chu]

How would you "turn off" or "ignore" a subsite in a simulcast cell, when they are literally all transmitting the 100% exactly identical RF? It's physically impossible and cannot be done, there is nothing in the RF that distinguishes one subsite from another, that's the entire point of a simulcasted signal.

Real subscribers are designed to handle the slightly out-of-phase signal that is inevitable in areas of simulcast overlap. It's actually not rocket science, it just requires the proper design of the receiver to make sense of it all. There are no fancy tricks like GPS on the subscribers, as again, that wouldn't do any good when there's no ability to differentiate between subsites regardless.

Thanks for your reply. As I said, I don’t get the simulcast problem having never encountering it. My posting was mostly an attempt at getting someone such as you to help me understand what parts of what I wrote are correct, approaching correct, or just plain off the wall. I thank you for helping.

 

[KevinC]

So before a packet data transmission, there is a handshake with the subscriber?

Not necessarily a handshake, but the system will pick the subsite that last received the subscriber the best and initially use that one. It will periodically update that uplink query. All subsites still receive the data, it's just steered on the downlink.

 

[qc]

if your using BCD996p2 as a base this will work Indoor 700/800 MHz Yagi Directional Antenna with Desktop Stand | Scanner Master

 

[btt]

I'm going to throw a bit of a wrench into this thread just for fun. In fact packet data is actually subsite steered whenever possible, rather than going out over every subsite in the simulcast cell like the voice traffic does. The system will broadcast the data over whichever subsite the subscriber last voted to. If that is unknown, then the data will go out over every subsite in the cell. This is done presumably because data doesn't play well with simulcast the same way voice traffic does.

Of course that has no bearing on a scanner receiving voice transmissions, but it is a tidbit for those who have interest in the nuts and bolts of these systems. I should say also that this applies to Motorola ASTRO 25 IV&D systems, I'm not sure if it applies to systems by other manufacturers.

When the data is steered through a single subsite, I assume this is only when dealing with a single subscriber-specific data exchange like authorization, etc? I would also assume the uninvolved subsites have a short period of dead time during this exchange?

 

[Project25_MASTR]

I'm going to throw a bit of a wrench into this thread just for fun. In fact packet data is actually subsite steered whenever possible, rather than going out over every subsite in the simulcast cell like the voice traffic does. The system will broadcast the data over whichever subsite the subscriber last voted to. If that is unknown, then the data will go out over every subsite in the cell. This is done presumably because data doesn't play well with simulcast the same way voice traffic does.

Of course that has no bearing on a scanner receiving voice transmissions, but it is a tidbit for those who have interest in the nuts and bolts of these systems. I should say also that this applies to Motorola ASTRO 25 IV&D systems, I'm not sure if it applies to systems by other manufacturers.

Professionally I've not dealt with an IV&D system that is utilizing packet data. Was this true of HPD or packet use on IV&D in general?

There's my TIL.

 

[GTR8000]

For those asking about further details about the data being steered to specific subsites, here's the description right out of the ASTRO 25 Trunked Data Services Feature Guide. We're starting to drift off course (what else is new), so I'll end the discussion on this note, as I'm sure y'all can find additional documentation on your own if you're that interested in how it works.

 

[epersson]

Unfortunately the only realistic fix is to buy an SDS. As far as I know that's the only thing on the market that can handle simulcast. I've got some SDR's that handle it "OK" for the most part (it's really the software that handles it, SDRTrunk), but it definitely has days where it's so distorted you can't make much out of what is being said.

There's a good video floating around here where someone covered a couple of different things to help with distortion. I can't find the link, but maybe someone will post it. In my situation, I was under the impression that I needed a better antenna when it was the complete opposite. I actually took steps to reduce the signal quality and the audio got better. Sometimes I just run the SDR's with no antenna at all and it works, somehow.

If you don't want to spend $600+and can put up with a very responsive development when issues are found I would strongly suggest the P25rx, @btt commented later in this feed, but his lack of self promotion kept him from mentioning he designed and built it.
BlueTail Technlogies – BlueTail Technologies

If you want to listen to a live feed of it my Broadcastify feed is up on multiple systems, the main being a P25p2 simulcast that killed a 996p2.
Broward County Fire-Rescue Live Audio Feed (broadcastify.com)

 

[KA1RBI]

How would you "turn off" or "ignore" a subsite in a simulcast cell, when they are literally all transmitting the 100% exactly identical RF? It's physically impossible and cannot be done, there is nothing in the RF that distinguishes one subsite from another, that's the entire point of a simulcasted signal.

Real subscribers are designed to handle the slightly out-of-phase signal that is inevitable in areas of simulcast overlap. It's actually not rocket science, it just requires the proper design of the receiver to make sense of it all. There are no fancy tricks like GPS on the subscribers, as again, that wouldn't do any good when there's no ability to differentiate between subsites regardless.

Subscriber units cannot "turn off" or "ignore" subsites, but the RF that is transmitted is not necessarily "100% exactly identical" between the subsites.

See Motorola US Patent 6,061,574, "Method and apparatus in a wireless communication system for reducing errors caused by intersymbol interference during a simulcast transmission".

I can confirm this modulation method is in use - by direct observation of a local /\/\ LSM-style P25 system. The P25 data bits are indeed identical but in the time periods between the data symbols (referred to as "non-central symbol portions" in the patent) as well as in the symbol central portions the relative phase and amplitude can and do vary between subsites (towers) in the system.

Where this is done the ISI-reduction is for the benefit of system subscibers - *not* for you as a third party listening on the call.

Max

 

[cg]

I will throw this out for the experts. For years, the P25 Simulcast system in CT was readily monitored by the various P25 700/800 capable scanners. It was when the system changed to Phase 2 that the monitoring went to crap. To be sure, it wasn't perfect before but I would say that it was 90%+ decent reception. The few remaining Phase 1 talkgroups can still be heard with the older equipment, again, not 100% but OK enough for casual monitoring.

 

[hiegtx]

I will throw this out for the experts. For years, the P25 Simulcast system in CT was readily monitored by the various P25 700/800 capable scanners. It was when the system changed to Phase 2 that the monitoring went to crap. To be sure, it wasn't perfect before but I would say that it was 90%+ decent reception. The few remaining Phase 1 talkgroups can still be heard with the older equipment, again, not 100% but OK enough for casual monitoring.

I don't claim to be a radio systems "expert", but you may have an excellent point. For a Phase I system, the transmission is digital, but also continuous. The receiver's architecture & design may be flexible, or 'forgiving', enough that it can smooth out the ripples of the slightly out of sync signals that arrive at the radio. However, that does not always work, especially in systems with a multitude of transmitter sites, instead of only a couple.

Phase II, on the other hand, is not 'continuous' in the sense that a Phase I signal is. Instead, it's alternating two entirely separate conversations between the two slots. So, while the scanner is receiving conversation A in 'slot 1', it's also getting bits & pieces of an entirely different conversation B occurring in 'slot 2' using the same frequency, from a transmitter at a different location. Unless a receiver is 'smart' enough to know the difference & process the signals accordingly, the end result is our frustrating simulcast distortion.

I share your impression that complaints about possible simulcast distortion do seem to occur much more often when a P25 Phase II system, is in play, than with a Phase I system.

 

[slicerwizard]

Phase II, on the other hand, is not 'continuous' in the sense that a Phase I signal is. Instead, it's alternating two entirely separate conversations between the two slots.

Irrelevant. Issues with Phase II decoding would be related to physical signal differences, such as Phase II's higher data rate.