I feel like, as in almost all good software development lifecycles, good use-cases need to be defined and the requirements built and prioritized from there. Certainly there is an argument to generate

#hblink

Taken directly from the rules sample file: * SYSTEM - The name of the sytem as listed in the main hblink configuration file (e.g. hblink.cfg) This MUST be the exact same name as in the main config fil

Randy - it would be great if you could add other contributors to the repository so that others are able to contribute / respond to bug/support matters / review and accept PRs etc...

Sometimes the order in which your dictionary is built has an impact on this.. I'm not sure why _shrug_... try reordering so that your lowest defined TGs are ordered first etc...

I’ll ping you off list - happy to add to the dev efforts. Sent from the iRoad

#hblink

I've also run into this issue - I submitted a pull request a while back that deals with it by allowing you to more easily run two ipsc_bridge instances (one for each TS).. .modifications here: https:/

#hblink

Providing the error would be more than useful, almost necessary one might say..... Additionally - providing the actual config and rules files is necessary.. example: python requires that spacing be th

Cort - I think that it works great as it is and want to be sure that you know how important it has become to a number of clubs/organizations! The beauty of course also is that it's all Open Source and

So if the repeaters are masters and your system is the peer, the masters (repeaters) can be the same port, but you’ll need the local port of the peer config to be different... you just can’t bind loca

Different masters and different peers on the same ports will throw an error, no audio mixing... Sent from the iRoad

Openbridge is what you are looking for, search the mailer archives for piles of info. Sent from the iRoad

#hblink

If I understand the need, yes it can. But each hotspot which you want unique TGs on will need to have its own master instance that you can uniquely route the “private” calls to using the rules definit

#hblink

Jeff - I looked through your post and you are definitely tracking down the correct path. Ultimately you will confbridge.py along with the appropriate confbridge_rules.py to route the traffic between t

That is the whole point, you don't need BM at all. If one side is TXing when you TX to the other side... look at the logs, look at the dashboards to make sure the TG,TS,CC etc all match what you expec

#hblink

Well I fail lol Sent from the iRoad

No, there is a special branch being developed. Sent from the iRoad

You could also look at IP traffic coming in.. you will see a ton of traffic when all else is silent from his IP.. then block the IP at the firewall.

I'm running the latest 3.7 without issue. You could also always venv to test things and/or keep things clean too.

Depending on the branch that you are using (master I'm sure), neither private call nor data (SMS) capabilities exist yet. There are other branches, but I couldn't speak to their functionality at this

Agree - those should not all be required fields - maybe have a simple check box for people who don't want things listed publicly then the instance admin can be contacted if someone wants to connect to