-
-
Notifications
You must be signed in to change notification settings - Fork 206
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
Conversation
Nice Work! I am still trying to get my head around things. I dropped in some comments in places where I am confused. |
@robotastic pardon my ignorance...where can I find your comments? |
There was a problem hiding this 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.
Merge branch 'master' of https://github.com/aaknitt/trunk-recorder
@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.
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. |
@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. |
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. |
Yeah as far as I can tell it seems to be working well, I'd say go for it. |
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.