main@DVSwitch.groups.io | HBLink: Adhoc clients with routing rules, conferences etc

Matthew 2E0SIP

#50

Hi,

Please forgive me if this is an elementary question, but reading the example code hasnt made things any clearer.

From what I gather, The majority of the code covers routing between pre-defined networks. Does the functionality exist to route between adhoc clients connected to a HBLink master, or is it assumed this takes place "upstream"?

Thanks

Steve N4IRS

#51

Let's see if this helps. Below is the confbridge rules used for the simple demo running on reflector.dvswitch.org

BRIDGES = {
    'AllStarLink': [
            {'SYSTEM': 'BrandMeister', 'TS': 2, 'TGID': 3167, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
            {'SYSTEM': 'HBlink',       'TS': 2, 'TGID': 3167, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
        ],
    'Talker': [
            {'SYSTEM': 'Talker',       'TS': 1, 'TGID': 9999, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
            {'SYSTEM': 'HBlink',       'TS': 1, 'TGID': 9999, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
            {'SYSTEM': 'IPSC_bridge', 'TS': 1, 'TGID': 9999, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
        ],
    'Parrot': [
            {'SYSTEM': 'Parrot',       'TS': 2, 'TGID': 9990, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
            {'SYSTEM': 'HBlink',       'TS': 2, 'TGID': 9990, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
        ]
}

The SYSTEM is a Master or Peer defined in hblink.cfg
BrandMeister is a Peer to BM 3108
HBlink is a Master running on reflector.dvswitch.org
Talker is a Master running on reflector.dvswitch.org
IPSC_bridge is a Master running on reflector.dvswitch.org
Parrot is a Master running on reflector.dvswitch.org

Traffic to and from BM on TS2/TG3167 is bridged to any Peer connected to the Master HBlink
Traffic is bridged between Talker, HBlink and IPSC_bridge on TS1/TG9999
Traffic is bridged between Parrot and HBlink on TS2/9990

Show quoted text

On 5/30/2017 2:38 PM, marrold.co.uk wrote:

Hi,

Please forgive me if this is an elementary question, but reading the example code hasnt made things any clearer.

From what I gather, The majority of the code covers routing between pre-defined networks. Does the functionality exist to route between adhoc clients connected to a HBLink master, or is it assumed this takes place "upstream"?

Thanks

Matthew 2E0SIP

#52

Hi Steve,

Thanks for sharing the configuration, that confirms the understanding I have so far.

To clarify my question, if HBLink is acting as a master only, without any additional systems, are DMR frames passed between connected clients? If so, is it possible to apply the timeouts and 'rules' to inter-client traffic?

If this isn't currently a feature of HBLink, is it supported in DMRLink or the upcoming 'DVSwitch'?

Thanks again for your assistance and contributions to DMR.

Matthew
2E0SIP

Peter M0NWI

#53

Matthew,

In DMRLink, which HBLink is based on, you have to explicitly allow routing in the bridge application from one repeater host to any other, even hosted under the same instance.

73,
Peter

Sent from Outlook

From: DVSwitch@groups.io <DVSwitch@groups.io> on behalf of marrold.co.uk <groups.io@...>
Sent: 30 May 2017 21:36:32
To: DVSwitch@groups.io
Subject: Re: [DVSwitch] HBLink: Adhoc clients with routing rules, conferences etc

Hi Steve,

Thanks for sharing the configuration, that confirms the understanding I have so far.

To clarify my question, if HBLink is acting as a master only, without any additional systems, are DMR frames passed between connected clients? If so, is it possible to apply the timeouts and 'rules' to inter-client traffic?

If this isn't currently a feature of HBLink, is it supported in DMRLink or the upcoming 'DVSwitch'?

Thanks again for your assistance and contributions to DMR.

Matthew
2E0SIP

Matthew Pitts N8OHU

#54

Matthew,

I believe that, or something close to it, is the purpose of the On and Off entries in each rule. The ones that Steve showed us are empty, but they would hold Talkgroups defined for the purpose of enabling and disabling rules.

Matthew Pitts
N8OHU

Show quoted text

On May 30, 2017 4:36:32 PM EDT, "marrold.co.uk" <groups.io@marrold.co.uk> wrote:

Hi Steve,

Thanks for sharing the configuration, that confirms the understanding I have so far.

To clarify my question, if HBLink is acting as a master only, without any additional systems, are DMR frames passed between connected clients? If so, is it possible to apply the timeouts and 'rules' to inter-client traffic?

If this isn't currently a feature of HBLink, is it supported in DMRLink or the upcoming 'DVSwitch'?

Thanks again for your assistance and contributions to DMR.

Matthew
2E0SIP

Cort <n0mjs@...>

#55

There is a switch in the configuration on a “per-system” basis in HBlink:

REPEAT:

If this is set to True, HBlink will repeat ALL traffic between HBP repeaters (hotspots, etc.) connected to that master. If it is set to False, it will not. If you want to restrict what passes from HBP repeaters, connect them to different masters and use bridging rules.

On May 30, 2017, at 3:36 PM, marrold.co.uk <groups.io@...> wrote:

Hi Steve,
Thanks for sharing the configuration, that confirms the understanding I have so far.

To clarify my question, if HBLink is acting as a master only, without any additional systems, are DMR frames passed between connected clients? If so, is it possible to apply the timeouts and 'rules' to inter-client traffic?
If this isn't currently a feature of HBLink, is it supported in DMRLink or the upcoming 'DVSwitch'?

Thanks again for your assistance and contributions to DMR.

Matthew
2E0SIP

--

Cort Buffington

H: +1-785-813-1501

M: +1-785-865-7206

Cort <n0mjs@...>

#56

On May 30, 2017, at 4:25 PM, Peter Martin <peter-martin@...> wrote:

Matthew,

In DMRLink, which HBLink is based on, you have to explicitly allow routing in the bridge application from one repeater host to any other, even hosted under the same instance.

As stated earlier, not entirely true – if you set “REPEAT: True” for an HBP system in the config, it will blindly forward all traffic to all other machines connected to that master.

73,
Peter

Sent from Outlook

From: DVSwitch@groups.io <DVSwitch@groups.io> on behalf of marrold.co.uk <groups.io@...>
Sent: 30 May 2017 21:36:32
To: DVSwitch@groups.io
Subject: Re: [DVSwitch] HBLink: Adhoc clients with routing rules, conferences etc

Hi Steve,
Thanks for sharing the configuration, that confirms the understanding I have so far.

To clarify my question, if HBLink is acting as a master only, without any additional systems, are DMR frames passed between connected clients? If so, is it possible to apply the timeouts and 'rules' to inter-client traffic?
If this isn't currently a feature of HBLink, is it supported in DMRLink or the upcoming 'DVSwitch'?

Thanks again for your assistance and contributions to DMR.

Matthew
2E0SIP

--

Cort Buffington

H: +1-785-813-1501

M: +1-785-865-7206

Cort <n0mjs@...>

#57

Again, as stated earlier the purpose of the “REPEAT:” configuration in HBlink.

Line from the comments in the sample configuration file:

# Repeat - if True, the master repeats traffic to clients, False, it does nothing.

This isn’t entirely clear, but what it means is the particulate instance of HBlink, if it is a master, this will make it repeat everything to every client connected to that master.

On May 30, 2017, at 4:30 PM, Matthew Pitts via Groups.Io <n8ohu@...> wrote:

Matthew,

I believe that, or something close to it, is the purpose of the On and Off entries in each rule. The ones that Steve showed us are empty, but they would hold Talkgroups defined for the purpose of enabling and disabling rules.

Matthew Pitts
N8OHU

On May 30, 2017 4:36:32 PM EDT, "marrold.co.uk" <groups.io@marrold.co.uk> wrote:
Hi Steve,
Thanks for sharing the configuration, that confirms the understanding I have so far.

To clarify my question, if HBLink is acting as a master only, without any additional systems, are DMR frames passed between connected clients? If so, is it possible to apply the timeouts and 'rules' to inter-client traffic?
If this isn't currently a feature of HBLink, is it supported in DMRLink or the upcoming 'DVSwitch'?

Thanks again for your assistance and contributions to DMR.

Matthew
2E0SIP

--

Cort Buffington

H: +1-785-813-1501

M: +1-785-865-7206

Matthew 2E0SIP

#58

Thanks all, I think that has clarified it. Much appreciated.

73
Matthew
2E0SIP

Matthew Pitts N8OHU

#59

Thanks for the clarification, Cort.

Matthew Pitts

N8OHU

Show quoted text

On 5/30/2017 5:44 PM, Cort wrote:

Again, as stated earlier the purpose of the “REPEAT:” configuration in HBlink.

Line from the comments in the sample configuration file:

# Repeat - if True, the master repeats traffic to clients, False, it does nothing.

This isn’t entirely clear, but what it means is the particulate instance of HBlink, if it is a master, this will make it repeat everything to every client connected to that master.

On May 30, 2017, at 4:30 PM, Matthew Pitts via Groups.Io <n8ohu@...> wrote:

Matthew,

I believe that, or something close to it, is the purpose of the On and Off entries in each rule. The ones that Steve showed us are empty, but they would hold Talkgroups defined for the purpose of enabling and disabling rules.

Matthew Pitts
N8OHU

On May 30, 2017 4:36:32 PM EDT, "marrold.co.uk" <groups.io@marrold.co.uk> wrote:

Hi Steve,

Thanks for sharing the configuration, that confirms the understanding I have so far.

To clarify my question, if HBLink is acting as a master only, without any additional systems, are DMR frames passed between connected clients? If so, is it possible to apply the timeouts and 'rules' to inter-client traffic?

If this isn't currently a feature of HBLink, is it supported in DMRLink or the upcoming 'DVSwitch'?

Thanks again for your assistance and contributions to DMR.

Matthew
2E0SIP

--

Cort Buffington

H: +1-785-813-1501

M: +1-785-865-7206

Peter M0NWI

#60

Sorry Cort, as I said I was going on my experience of DMRlink as I've not used HBlink, thanks for clarifying.

73

Sent from Outlook

From: DVSwitch@groups.io <DVSwitch@groups.io> on behalf of Cort <n0mjs@...>
Sent: 30 May 2017 22:42:30
To: DVSwitch@groups.io
Subject: Re: [DVSwitch] HBLink: Adhoc clients with routing rules, conferences etc

On May 30, 2017, at 4:25 PM, Peter Martin <peter-martin@...> wrote:

Matthew,

In DMRLink, which HBLink is based on, you have to explicitly allow routing in the bridge application from one repeater host to any other, even hosted under the same instance.

As stated earlier, not entirely true – if you set “REPEAT: True” for an HBP system in the config, it will blindly forward all traffic to all other machines connected to that master.

73,
Peter

Sent from Outlook

From: DVSwitch@groups.io <DVSwitch@groups.io> on behalf of marrold.co.uk <groups.io@...>
Sent: 30 May 2017 21:36:32
To: DVSwitch@groups.io
Subject: Re: [DVSwitch] HBLink: Adhoc clients with routing rules, conferences etc

Hi Steve,

Thanks for sharing the configuration, that confirms the understanding I have so far.

To clarify my question, if HBLink is acting as a master only, without any additional systems, are DMR frames passed between connected clients? If so, is it possible to apply the timeouts and 'rules' to inter-client traffic?

If this isn't currently a feature of HBLink, is it supported in DMRLink or the upcoming 'DVSwitch'?

Thanks again for your assistance and contributions to DMR.

Matthew
2E0SIP

--

Cort Buffington

H: +1-785-813-1501

M: +1-785-865-7206

Cort <n0mjs@...>

#61

It was actually my attempt to give MMDVM users the "party line" feature from Motorola's IPSC... which feels like one of IPSC's worst "features"... until you don't have it anymore. But left it configurable so it really is a "feature" and not an "albatross" 😀

0x49 DE N0MJS

Sent from my iPhone

Show quoted text

On May 30, 2017, at 5:11 PM, Peter Martin <peter-martin@...> wrote:

Sorry Cort, as I said I was going on my experience of DMRlink as I've not used HBlink, thanks for clarifying.

73

Sent from Outlook

From: DVSwitch@groups.io <DVSwitch@groups.io> on behalf of Cort <n0mjs@...>
Sent: 30 May 2017 22:42:30
To: DVSwitch@groups.io
Subject: Re: [DVSwitch] HBLink: Adhoc clients with routing rules, conferences etc

On May 30, 2017, at 4:25 PM, Peter Martin <peter-martin@...> wrote:

Matthew,

In DMRLink, which HBLink is based on, you have to explicitly allow routing in the bridge application from one repeater host to any other, even hosted under the same instance.

As stated earlier, not entirely true – if you set “REPEAT: True” for an HBP system in the config, it will blindly forward all traffic to all other machines connected to that master.

73,
Peter

Sent from Outlook

From: DVSwitch@groups.io <DVSwitch@groups.io> on behalf of marrold.co.uk <groups.io@...>
Sent: 30 May 2017 21:36:32
To: DVSwitch@groups.io
Subject: Re: [DVSwitch] HBLink: Adhoc clients with routing rules, conferences etc

Hi Steve,

Thanks for sharing the configuration, that confirms the understanding I have so far.

To clarify my question, if HBLink is acting as a master only, without any additional systems, are DMR frames passed between connected clients? If so, is it possible to apply the timeouts and 'rules' to inter-client traffic?

If this isn't currently a feature of HBLink, is it supported in DMRLink or the upcoming 'DVSwitch'?

Thanks again for your assistance and contributions to DMR.

Matthew
2E0SIP

--

Cort Buffington

H: +1-785-813-1501

M: +1-785-865-7206

Steve N4IRS

#62

Cort,
Thanks for the definitive answer. I was "out of pocket" for a couple of hours.
In other news...
I am troubleshooting hb_parrot and working on the scripting for the Talker demo.

Steve

Show quoted text

On 05/30/2017 05:44 PM, Cort wrote:

Again, as stated earlier the purpose of the “REPEAT:” configuration in HBlink.

Line from the comments in the sample configuration file:

# Repeat - if True, the master repeats traffic to clients, False, it does nothing.

This isn’t entirely clear, but what it means is the particulate instance of HBlink, if it is a master, this will make it repeat everything to every client connected to that master.

On May 30, 2017, at 4:30 PM, Matthew Pitts via Groups.Io <n8ohu@...> wrote:

Matthew,

I believe that, or something close to it, is the purpose of the On and Off entries in each rule. The ones that Steve showed us are empty, but they would hold Talkgroups defined for the purpose of enabling and disabling rules.

Matthew Pitts
N8OHU

On May 30, 2017 4:36:32 PM EDT, "marrold.co.uk" <groups.io@marrold.co.uk> wrote:

Hi Steve,

Thanks for sharing the configuration, that confirms the understanding I have so far.

To clarify my question, if HBLink is acting as a master only, without any additional systems, are DMR frames passed between connected clients? If so, is it possible to apply the timeouts and 'rules' to inter-client traffic?

If this isn't currently a feature of HBLink, is it supported in DMRLink or the upcoming 'DVSwitch'?

Thanks again for your assistance and contributions to DMR.

Matthew
2E0SIP

--

Cort Buffington

H: +1-785-813-1501

M: +1-785-865-7206

Matthew Pitts N8OHU

#63

Okay, I think I have it, but to clarify; each system listed in the rules in the hb_confbridge._rules.py needs to be listed as a Master in the hblink.cfg file? How are the ports and IP addresses handled for each defined master? And how does one configure a master as a peer of another master?

Matthew Pitts

N8OHU

Show quoted text

On 5/30/2017 2:59 PM, Steve N4IRS wrote:

Let's see if this helps. Below is the confbridge rules used for the simple demo running on reflector.dvswitch.org

BRIDGES = {
    'AllStarLink': [
            {'SYSTEM': 'BrandMeister', 'TS': 2, 'TGID': 3167, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
            {'SYSTEM': 'HBlink',       'TS': 2, 'TGID': 3167, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
        ],
    'Talker': [
            {'SYSTEM': 'Talker',       'TS': 1, 'TGID': 9999, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
            {'SYSTEM': 'HBlink',       'TS': 1, 'TGID': 9999, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
            {'SYSTEM': 'IPSC_bridge', 'TS': 1, 'TGID': 9999, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
        ],
    'Parrot': [
            {'SYSTEM': 'Parrot',       'TS': 2, 'TGID': 9990, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
            {'SYSTEM': 'HBlink',       'TS': 2, 'TGID': 9990, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
        ]
}

The SYSTEM is a Master or Peer defined in hblink.cfg
BrandMeister is a Peer to BM 3108
HBlink is a Master running on reflector.dvswitch.org
Talker is a Master running on reflector.dvswitch.org
IPSC_bridge is a Master running on reflector.dvswitch.org
Parrot is a Master running on reflector.dvswitch.org

Traffic to and from BM on TS2/TG3167 is bridged to any Peer connected to the Master HBlink
Traffic is bridged between Talker, HBlink and IPSC_bridge on TS1/TG9999
Traffic is bridged between Parrot and HBlink on TS2/9990

On 5/30/2017 2:38 PM, marrold.co.uk wrote:

Hi,

Please forgive me if this is an elementary question, but reading the example code hasnt made things any clearer.

From what I gather, The majority of the code covers routing between pre-defined networks. Does the functionality exist to route between adhoc clients connected to a HBLink master, or is it assumed this takes place "upstream"?

Thanks

Steve N4IRS

#64

[HBlink]
MODE: MASTER
ENABLED: True
REPEAT: True
EXPORT_AMBE: False
IP:
PORT: 62031
PASSPHRASE: passw0rd
GROUP_HANGTIME: 5

[Parrot]
MODE: MASTER
ENABLED: True
REPEAT: True
EXPORT_AMBE: False
IP: 127.0.0.1
PORT: 62034
PASSPHRASE: passw0rd
GROUP_HANGTIME: 5

Above are 2 of the Masters from the hblink.cfg To have 2 Masters talk to each other, you have to bridge them. Like the Parrot bridge below.

Show quoted text

On 05/30/2017 07:18 PM, Matthew Pitts via Groups.Io wrote:

Okay, I think I have it, but to clarify; each system listed in the rules in the hb_confbridge._rules.py needs to be listed as a Master in the hblink.cfg file? How are the ports and IP addresses handled for each defined master? And how does one configure a master as a peer of another master?

Matthew Pitts

N8OHU

On 5/30/2017 2:59 PM, Steve N4IRS wrote:

Let's see if this helps. Below is the confbridge rules used for the simple demo running on reflector.dvswitch.org

BRIDGES = {
    'AllStarLink': [
            {'SYSTEM': 'BrandMeister', 'TS': 2, 'TGID': 3167, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
            {'SYSTEM': 'HBlink',       'TS': 2, 'TGID': 3167, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
        ],
    'Talker': [
            {'SYSTEM': 'Talker',       'TS': 1, 'TGID': 9999, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
            {'SYSTEM': 'HBlink',       'TS': 1, 'TGID': 9999, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
            {'SYSTEM': 'IPSC_bridge', 'TS': 1, 'TGID': 9999, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
        ],
    'Parrot': [
            {'SYSTEM': 'Parrot',       'TS': 2, 'TGID': 9990, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
            {'SYSTEM': 'HBlink',       'TS': 2, 'TGID': 9990, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
        ]
}

The SYSTEM is a Master or Peer defined in hblink.cfg
BrandMeister is a Peer to BM 3108
HBlink is a Master running on reflector.dvswitch.org
Talker is a Master running on reflector.dvswitch.org
IPSC_bridge is a Master running on reflector.dvswitch.org
Parrot is a Master running on reflector.dvswitch.org

Traffic to and from BM on TS2/TG3167 is bridged to any Peer connected to the Master HBlink
Traffic is bridged between Talker, HBlink and IPSC_bridge on TS1/TG9999
Traffic is bridged between Parrot and HBlink on TS2/9990

On 5/30/2017 2:38 PM, marrold.co.uk wrote:

Hi,

Please forgive me if this is an elementary question, but reading the example code hasnt made things any clearer.

From what I gather, The majority of the code covers routing between pre-defined networks. Does the functionality exist to route between adhoc clients connected to a HBLink master, or is it assumed this takes place "upstream"?

Thanks

Steve N4IRS

#65

I don't know of anyway that 2 Peers connected to 1 Master can have rules applied. I would setup hb_confbridge with 2 masters and then you could control the traffic between the 2 Peers. Both masters would be defined in hblink.cfg. They would have to listen 2 different UDP ports. Unless Cort or Mike correct me. ;)

Show quoted text

On 05/30/2017 04:36 PM, marrold.co.uk wrote:

Hi Steve,

Thanks for sharing the configuration, that confirms the understanding I have so far.

To clarify my question, if HBLink is acting as a master only, without any additional systems, are DMR frames passed between connected clients? If so, is it possible to apply the timeouts and 'rules' to inter-client traffic?

If this isn't currently a feature of HBLink, is it supported in DMRLink or the upcoming 'DVSwitch'?

Thanks again for your assistance and contributions to DMR.

Matthew
2E0SIP

Matthew 2E0SIP

#66

I had a look at the code and as it stands with Repeat=True DMR frames are simply forwarded to all connected clients.

One of my objectives would be to 'block' unused talk groups to prevent someone keying up on a wrong talk group blocking RF for other connected clients.

It also doesn't look outside the realms of possibility to do a 'lookup' on a particular talk group before routing it to clients that wish to receive it, E.G Similar to Brandmeister's self care portal where a user can assign certain static talk groups to their hotspot or repeater.

Anyway, I'm not sure if the above are the objectives of HBLink, but it looks possible so I will experiment in my own fork.

Thanks once again.

Matthew
2E0SIP

Steve N4IRS

#67

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.

Steve n4IRS

Cort <n0mjs@...>

#68

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@...> wrote:

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.

Steve n4IRS

Cort Buffington

785-865-7206

smime.p7s

Cort <n0mjs@...>

#69

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@...> wrote:

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@...> wrote:

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.

Steve n4IRS

Cort Buffington
785-865-7206

Cort Buffington

785-865-7206

smime.p7s