Date   

Re: Where do we stand?

Steve N4IRS
 
Edited

It looks like the DMO bug is squashed. I'm continuing to test today. If all goes well, I'll zip up the new files and expand the alpha test to add more people that voted in the naming question. (joking?)

Steve


Re: Where do we stand?

Matthew Pitts N8OHU
 

Nice work.

*watches bug go "ska-wish"*

Matthew

N8OHU


On 6/8/2017 7:35 PM, Steve N4IRS wrote:
Mike squashed a major bug in HB_bridge today. As of now it LOOKS like MMDVM Repeater <---> HB_bridge <---> IPSC_bridge <---> c-Bridge is working. There  is still a bug in DMO we hope to find and squash next.
The testing is being done in it's simplest form. No confbridge, simple partner to partner. I am zipping up the working copies to send to 2 alpha testers.

Steve 


Where do we stand?

Steve N4IRS
 

Mike squashed a major bug in HB_bridge today. As of now it LOOKS like MMDVM Repeater <---> HB_bridge <---> IPSC_bridge <---> c-Bridge is working. There  is still a bug in DMO we hope to find and squash next.
The testing is being done in it's simplest form. No confbridge, simple partner to partner. I am zipping up the working copies to send to 2 alpha testers.

Steve 


Re: HB_bridge and Analog_bridge

Corey Dean <n3fe@...>
 

Keep in mind, hoseline broke a little over a week ago.  There are many behind the scenes hoseline servers that feed to a master almost like a proxy.  Right now most are feeds no directly from Italy.  You can always try the US hoseline server that all the US masters feed into.  hose.repeater.net.  It is located in New York City.

Corey n3fe 

Sent from my iPhone

On Jun 7, 2017, at 9:24 AM, Richard (Joseph) VE2DJE <ve2dje@...> wrote:

Same setup this morning , Hoseline is working OK  ....

 

Richard

 

Provenance : Courrier pour Windows 10

 

De : Richard (Joseph) VE2DJE
Envoyé le :mercredi 7 juin 2017 08:49
À : DVSwitch@groups.io
Objet :Re: [DVSwitch] HB_bridge and Analog_bridge

 

Thanks . You guys are doing a fantastic job.....

 

Richard

 

Le 7 juin 2017 08:36, "Steve N4IRS" <szingman@...> a écrit :

Richard,
Analog_bridge, HB_bridge and IPSC_bridge are going through multiple changes every day. A number of things that we originally thought have been changed. The code has been refactored to make it more modular and easier to extend.
I'm sorry for the delay.

I checked hoseline this morning, my audio was there for 3167. One of the issues with BM is that the servers get "bounced" pretty often. HBlink needs to reconnect. That needs to be looked at.

Steve

On 6/6/2017 4:16 PM, Richard (Joseph) VE2DJE wrote:

Tested  my mmdvm repeater  on reflector.dvswitch.org port 62031.

 

Works OK  on 9900 parrot  and on 3167 .

 

Looked on Brandmeister Last Heard list  ,  Callsign are showing  OK…

 

But no luck with  Hoseline.  Not showing my call sign nor audio…

 

Also tested   local  hb_parrot.py  , all OK ,  local Parrot is working fine .

 

Still working   with hb_bridge_all.py and hb_confbridge.py .

 

Lot of reading and  brain  cramps…

 

Looked trough the Wiki to find  HB_bridge or Analog_bridge partners apps ( ????),

 

Are they available for testing  yet ?????   Shure  willing to  give it a try …..

 

Testing  on  ambe_audio and  DMRGateway ( before renaming to Analog_bridge )  where

 

a great learning tool….

 

thanks

 

Richard VE2DJE

 

 

Provenance : Courrier pour Windows 10

 

 

 

<7C3ABCC0BA3E4D0DB56781FCA393BAA3.png>


Re: HB_bridge and Analog_bridge

 

Same setup this morning , Hoseline is working OK  ....

 

Richard

 

Provenance : Courrier pour Windows 10

 

De : Richard (Joseph) VE2DJE
Envoyé le :mercredi 7 juin 2017 08:49
À : DVSwitch@groups.io
Objet :Re: [DVSwitch] HB_bridge and Analog_bridge

 

Thanks . You guys are doing a fantastic job.....

 

Richard

 

Le 7 juin 2017 08:36, "Steve N4IRS" <szingman@...> a écrit :

Richard,
Analog_bridge, HB_bridge and IPSC_bridge are going through multiple changes every day. A number of things that we originally thought have been changed. The code has been refactored to make it more modular and easier to extend.
I'm sorry for the delay.

I checked hoseline this morning, my audio was there for 3167. One of the issues with BM is that the servers get "bounced" pretty often. HBlink needs to reconnect. That needs to be looked at.

Steve

On 6/6/2017 4:16 PM, Richard (Joseph) VE2DJE wrote:

Tested  my mmdvm repeater  on reflector.dvswitch.org port 62031.

 

Works OK  on 9900 parrot  and on 3167 .

 

Looked on Brandmeister Last Heard list  ,  Callsign are showing  OK…

 

But no luck with  Hoseline.  Not showing my call sign nor audio…

 

Also tested   local  hb_parrot.py  , all OK ,  local Parrot is working fine .

 

Still working   with hb_bridge_all.py and hb_confbridge.py .

 

Lot of reading and  brain  cramps…

 

Looked trough the Wiki to find  HB_bridge or Analog_bridge partners apps ( ????),

 

Are they available for testing  yet ?????   Shure  willing to  give it a try …..

 

Testing  on  ambe_audio and  DMRGateway ( before renaming to Analog_bridge )  where

 

a great learning tool….

 

thanks

 

Richard VE2DJE

 

 

Provenance : Courrier pour Windows 10

 

 

 


Re: Yaesu DR-2X inbuilt ethernet and bridging.

Matthew Pitts N8OHU
 

Steve,

Yaesu uses the same vocoder as DMR for DN, and a vocoder similar to P-25 for the higher rate voice. Someone will have to wireshark the rest of the protocol though.

Matthew Pitts
N8OHU


On June 7, 2017 9:04:59 AM EDT, Steve N4IRS <szingman@...> wrote:
Knowing Yaesu, it will be closed. All I can say is let the fun continue...

On 6/7/2017 8:56 AM, Peter Martin wrote:

All,


I understand from Yaesu that the new version of the Fusion repeater is to have an ethernet interface as standard, and that they are including a protocol to link repeaters like IPSC, referred to as IMRS (Internet-linked Multi-site Repeater System).


I wondered is anyone else has heard or seen anymore on this protocol, to allow it to reviewed and see if it would be possible to add it as another option into DVSwitch?


I suppose the kicker will be if it uses a much different AMBE encoder and so they are compatible or not on the WAN side.


73,
Peter


Re: Yaesu DR-2X inbuilt ethernet and bridging.

Steve N4IRS
 

Knowing Yaesu, it will be closed. All I can say is let the fun continue...

On 6/7/2017 8:56 AM, Peter Martin wrote:

All,


I understand from Yaesu that the new version of the Fusion repeater is to have an ethernet interface as standard, and that they are including a protocol to link repeaters like IPSC, referred to as IMRS (Internet-linked Multi-site Repeater System).


I wondered is anyone else has heard or seen anymore on this protocol, to allow it to reviewed and see if it would be possible to add it as another option into DVSwitch?


I suppose the kicker will be if it uses a much different AMBE encoder and so they are compatible or not on the WAN side.


73,
Peter


Yaesu DR-2X inbuilt ethernet and bridging.

Peter M0NWI
 

All,


I understand from Yaesu that the new version of the Fusion repeater is to have an ethernet interface as standard, and that they are including a protocol to link repeaters like IPSC, referred to as IMRS (Internet-linked Multi-site Repeater System).


I wondered is anyone else has heard or seen anymore on this protocol, to allow it to reviewed and see if it would be possible to add it as another option into DVSwitch?


I suppose the kicker will be if it uses a much different AMBE encoder and so they are compatible or not on the WAN side.


73,
Peter


Re: HB_bridge and Analog_bridge

 

Thanks . You guys are doing a fantastic job.....

Richard

Le 7 juin 2017 08:36, "Steve N4IRS" <szingman@...> a écrit :
Richard,
Analog_bridge, HB_bridge and IPSC_bridge are going through multiple changes every day. A number of things that we originally thought have been changed. The code has been refactored to make it more modular and easier to extend.
I'm sorry for the delay.

I checked hoseline this morning, my audio was there for 3167. One of the issues with BM is that the servers get "bounced" pretty often. HBlink needs to reconnect. That needs to be looked at.

Steve

On 6/6/2017 4:16 PM, Richard (Joseph) VE2DJE wrote:

Tested  my mmdvm repeater  on reflector.dvswitch.org port 62031.

 

Works OK  on 9900 parrot  and on 3167 .

 

Looked on Brandmeister Last Heard list  ,  Callsign are showing  OK…

 

But no luck with  Hoseline.  Not showing my call sign nor audio…

 

Also tested   local  hb_parrot.py  , all OK ,  local Parrot is working fine .

 

Still working   with hb_bridge_all.py and hb_confbridge.py .

 

Lot of reading and  brain  cramps…

 

Looked trough the Wiki to find  HB_bridge or Analog_bridge partners apps ( ????),

 

Are they available for testing  yet ?????   Shure  willing to  give it a try …..

 

Testing  on  ambe_audio and  DMRGateway ( before renaming to Analog_bridge )  where

 

a great learning tool….

 

thanks

 

Richard VE2DJE

 

 

Provenance : Courrier pour Windows 10

 



Re: HB_bridge and Analog_bridge

Steve N4IRS
 

Richard,
Analog_bridge, HB_bridge and IPSC_bridge are going through multiple changes every day. A number of things that we originally thought have been changed. The code has been refactored to make it more modular and easier to extend.
I'm sorry for the delay.

I checked hoseline this morning, my audio was there for 3167. One of the issues with BM is that the servers get "bounced" pretty often. HBlink needs to reconnect. That needs to be looked at.

Steve

On 6/6/2017 4:16 PM, Richard (Joseph) VE2DJE wrote:

Tested  my mmdvm repeater  on reflector.dvswitch.org port 62031.

 

Works OK  on 9900 parrot  and on 3167 .

 

Looked on Brandmeister Last Heard list  ,  Callsign are showing  OK…

 

But no luck with  Hoseline.  Not showing my call sign nor audio…

 

Also tested   local  hb_parrot.py  , all OK ,  local Parrot is working fine .

 

Still working   with hb_bridge_all.py and hb_confbridge.py .

 

Lot of reading and  brain  cramps…

 

Looked trough the Wiki to find  HB_bridge or Analog_bridge partners apps ( ????),

 

Are they available for testing  yet ?????   Shure  willing to  give it a try …..

 

Testing  on  ambe_audio and  DMRGateway ( before renaming to Analog_bridge )  where

 

a great learning tool….

 

thanks

 

Richard VE2DJE

 

 

Provenance : Courrier pour Windows 10

 



HB_bridge and Analog_bridge

 

Tested  my mmdvm repeater  on reflector.dvswitch.org port 62031.

 

Works OK  on 9900 parrot  and on 3167 .

 

Looked on Brandmeister Last Heard list  ,  Callsign are showing  OK…

 

But no luck with  Hoseline.  Not showing my call sign nor audio…

 

Also tested   local  hb_parrot.py  , all OK ,  local Parrot is working fine .

 

Still working   with hb_bridge_all.py and hb_confbridge.py .

 

Lot of reading and  brain  cramps…

 

Looked trough the Wiki to find  HB_bridge or Analog_bridge partners apps ( ????),

 

Are they available for testing  yet ?????   Shure  willing to  give it a try …..

 

Testing  on  ambe_audio and  DMRGateway ( before renaming to Analog_bridge )  where

 

a great learning tool….

 

thanks

 

Richard VE2DJE

 

 

Provenance : Courrier pour Windows 10

 


Re: HBLink: Adhoc clients with routing rules, conferences etc

Matthew Pitts N8OHU
 

Works fine. Now to do some experiments.

Matthew Pitts
N8OHU


On May 30, 2017 7:26:26 PM EDT, Steve N4IRS <szingman@...> wrote:
[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.

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 




Re: HBLink: Adhoc clients with routing rules, conferences etc

Matthew 2E0SIP
 

Hi Cort,

Thanks for the advice.  I consider myself a 'novice' python user, but the current code is very clear so I'm sure I can follow your current methodology.

I will have a play in my own private fork and see where I get to.


Thanks again

Matthew

2E0SIP


Re: HBLink: Adhoc clients with routing rules, conferences etc

Cort <n0mjs@...>
 

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


Re: HBLink: Adhoc clients with routing rules, conferences etc

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


Re: HBLink: Adhoc clients with routing rules, conferences etc

Steve N4IRS
 

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


Re: HBLink: Adhoc clients with routing rules, conferences etc

Matthew 2E0SIP
 

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

 


Re: HBLink: Adhoc clients with routing rules, conferences etc

Steve N4IRS
 

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. ;)

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



Re: HBLink: Adhoc clients with routing rules, conferences etc

Steve N4IRS
 

[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.

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 




Re: HBLink: Adhoc clients with routing rules, conferences etc

Matthew Pitts N8OHU
 

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 


9801 - 9820 of 9882