You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Not sure if this is feasible or even desirable, but throwing out an idea:
On my local system dispatchers will often simulselect/multicast multiple talkgroups for things like "attempt to locate" bulletins, severe weather notifications, etc. This is different from patching in that the simulselect/multicast gets a channel grant for each talkgroup, so the same exact transmission is going out on multiple frequencies at the same time on the system. This can result in several minutes of the same transmission playing over and over again on OpenMHz, rdio-scanner, etc. as the same audio from each individual recording/frequency gets played back to back.
I'm wondering if it would be worth having each individual recording check to see if any other active recordings are originating from the same radio/unit, and if so, abort all but one of the recordings while adding the talkgroup ID of the aborted recordings to the Call data of the one that remains. From that point it could be handled in the same or similar manner as patched talkgroups - one recording with metadata showing all of the talkgroups that were simulselected/multicasted to.
Might get a bit tricky and not sure if doing something like this would break desired operation in some cases.
The text was updated successfully, but these errors were encountered:
Huh! that is an interesting idea! It could work if the message coming in that starts the call is a GRANT message.... which is almost always the case. The only time this does not happen is when a GRANT message is missed.
The only problem, would then be that you would have to block any subsequent Update messages from start a recording. I think this could be done if you start a Call for the transmission, but put it in Monitor state so it is tracked but not recorded.
Anyhow this might be doable without a ton of changes.
Is there ever a chance that two radios with the same ID could be on the system at the same time?
Is there ever a chance that two radios with the same ID could be on the system at the same time?
Good question. I've heard sketchy stories about people cloning radio IDs in the early days of trunked radio because they wanted to listen to the systems before scanners that did trunk-tracking became available, but I have to think that practice has long since ended. I can't think of a reason why the same radio ID should be in use by more than one radio, but I'm not an expert.
Not sure if this is feasible or even desirable, but throwing out an idea:
On my local system dispatchers will often simulselect/multicast multiple talkgroups for things like "attempt to locate" bulletins, severe weather notifications, etc. This is different from patching in that the simulselect/multicast gets a channel grant for each talkgroup, so the same exact transmission is going out on multiple frequencies at the same time on the system. This can result in several minutes of the same transmission playing over and over again on OpenMHz, rdio-scanner, etc. as the same audio from each individual recording/frequency gets played back to back.
I'm wondering if it would be worth having each individual recording check to see if any other active recordings are originating from the same radio/unit, and if so, abort all but one of the recordings while adding the talkgroup ID of the aborted recordings to the Call data of the one that remains. From that point it could be handled in the same or similar manner as patched talkgroups - one recording with metadata showing all of the talkgroups that were simulselected/multicasted to.
Might get a bit tricky and not sure if doing something like this would break desired operation in some cases.
The text was updated successfully, but these errors were encountered: