I should also add that it’s important to understand the sub-classing and inheritance used with these applications. Please, please, please consider calling hblink.py or dmrlink.py as modules, overriding class methods for added application flexibility instead of just adding it all directly to HBlink.py (for example).
On May 31, 2017, at 9:03 AM, Cort <n0mjs@...
I would ask that functionality be *added* without removing either of the two simple options with the master today. Also, for anyone adding functionality — especially things that go directly into HBlink.py and DMRlink.py — be particularly careful about processing time added. The philosophy is that moderately busy systems should run well on hardware as modest as Raspberry Pi. I typically use timing code when adding things to test additional processing time taken and re-factor several times over in an attempt to keep things clean and fast, and with a minimum of external modules imported; and ones that are get vetted carefully to ensure they’re well written.
Not trying to scare anyone off, but please keep this in mind when you’re adding to the base code; HBlink.py and DMRlink.py are intended to be little more than base protocol stacks intended to be kept clean, fast, and “generic”.
0x49 DE N0MJS
On May 31, 2017, at 7:08 AM, Steve N4IRS <szingman@...
I can see the use case for a whitelist of TS/TG when hblink.py is used in the simple configuration of being a single Master. Once you have something working, submit a pull request so it can be looked at.