Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Motorola talkgroup patch following to System info #562

Merged
merged 14 commits into from
Dec 12, 2021

Conversation

aaknitt
Copy link
Contributor

@aaknitt aaknitt commented Nov 29, 2021

I'm not very strong in C++ so feel free to suggest changes, I'm happy to tackle them as needed.

The current data structure holding the patch information doesn't indicate which of the patched talkgroups is the "sg" supergroup that is actually being used for transmissions. I don't think that matters or not from a practical standpoint but if it useful, we'll need to come up with a slightly different structure.

@robotastic
Copy link
Collaborator

Nice Work! I am still trying to get my head around things. I dropped in some comments in places where I am confused.

@aaknitt
Copy link
Contributor Author

aaknitt commented Dec 1, 2021

@robotastic pardon my ignorance...where can I find your comments?

Copy link
Collaborator

@robotastic robotastic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry - I tried to do a review and forgot to hit submit.

@EllioTTDawson
Copy link

@aaknitt

@EllioTTDawson
Copy link

#565

@aaknitt
Copy link
Contributor Author

aaknitt commented Dec 4, 2021

@robotastic I've been thinking that it may make sense to add the patches that a call/talkgroup is part of to the Call class when a new Call instance is created. This would allow all consumers of a Call to quickly get patches associated with that Call's talkgroup without having to iterate over all patches in the System each time (just iterate once when the Call is created).

So the System would still be the source of all patches on that System, but the Call would contain info for the single patch it's part of.

Thoughts?

… in the patch will be used when determining whether to start a recorder.
@aaknitt
Copy link
Contributor Author

aaknitt commented Dec 5, 2021

@robotastic I've been thinking that it may make sense to add the patches that a call/talkgroup is part of to the Call class when a new Call instance is created. This would allow all consumers of a Call to quickly get patches associated with that Call's talkgroup without having to iterate over all patches in the System each time (just iterate once when the Call is created).

So the System would still be the source of all patches on that System, but the Call would contain info for the single patch it's part of.

Thoughts?

I think I've decided this isn't needed. The sys->get_get_talkgroup_patch() works to get this info and since a map is used iteration shouldn't be too much of a concern.

@robotastic
Copy link
Collaborator

@aaknitt - I am not against adding a vector of patched talk groups to the Call object... but if we can get things working by just using the System object, that would be cool. Keeping the code pretty central will help if we find there are some changes needed later.

@robotastic
Copy link
Collaborator

Let me know if you think things are good. Other folks have gotten it working and the approach looks good. I can merge it this weekend.

@aaknitt
Copy link
Contributor Author

aaknitt commented Dec 11, 2021

Yeah as far as I can tell it seems to be working well, I'd say go for it.

@robotastic robotastic merged commit a4a8e99 into TrunkRecorder:master Dec 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants