Re: If you use HBlink OR dmr_utils, you need to read this

Cort N0MJS <n0mjs@...>

A bit more now the I’m on a real computer. The way those streams get processed on the TX side, I’ve not found a really efficient way to terminate them with the call end. The efficient place would be right before the stream metadata is used for forwarding, necessitating another check fo the same condition again after forwarding… I’m trying to find a better way, but letting them timeout isn’t a problem. It just keeps entries in a list a few seconds longer.

On Jan 14, 2019, at 4:26 PM, Cort N0MJS via Groups.Io <n0mjs@...> wrote:

Not an error. TX streams have to time out for not. There’s no explicit end for OBP TX streams yet

On Jan 14, 2019, at 2:41 PM, JJ Cummings <cummingsj@...> wrote:

Cort - great stuff I just switched over so the stack now looks like this (for those that care)

DMRLink <-> IPSC_Bridge <-> HB_Bridge <-> hblink3(bridge) <-> Analog_Bridge <-> ASL

On a separate note, I noted a an error in the log specifically related  to openbridge (outbound only connections) looks like it's not registering that the END event has occurred when it happens and thusly it times out?.  Posting here but hopefully I can post a pull request if ever I get time to debug at all.

INFO 2019-01-14 14:16:30,526 (ANALOG_BRIDGE) *CALL END*   STREAM ID: 2752969323 SUB: 1108389 (1108389) PEER: 310857 (310857) TGID 310815 (310815), TS 1, Duration: 3.02
INFO 2019-01-14 14:16:35,780 (OBP-3103) *TIME OUT*   STREAM ID: 2752969323 SUB: 1108389 PEER: 310885350 TGID: 310815 TS 1 Duration: 3.02
INFO 2019-01-14 14:19:21,827 (ANALOG_BRIDGE) *CALL START* STREAM ID: 205043449 SUB: 1108389 (1108389) PEER: 310857 (310857) TGID 310815 (310815), TS 1
INFO 2019-01-14 14:19:21,878 (ANALOG_BRIDGE) Conference Bridge: 310815, Call Bridged to OBP System: OBP-3103 TS: 1, TGID: 310815
INFO 2019-01-14 14:19:24,859 (ANALOG_BRIDGE) *CALL END*   STREAM ID: 205043449 SUB: 1108389 (1108389) PEER: 310857 (310857) TGID 310815 (310815), TS 1, Duration: 3.03
INFO 2019-01-14 14:19:30,780 (OBP-3103) *TIME OUT*   STREAM ID: 205043449 SUB: 1108389 PEER: 310885350 TGID: 310815 TS 1 Duration: 3.03

On Fri, Jan 11, 2019 at 11:04 AM Cort N0MJS via Groups.Io <> wrote:


If you go looking at my repos on GitHub, you’ll see a couple of new things:

HBlink3 and dmr_utils3

These are Python3 versions of HBlink and dmr_utils. Currently, dmr_utils3 does not include and HBlink3 does not include parrot or bridge_all – effectively leaving it as the base stack and the conference bridge application… there have also been some things renamed. I removed “hb_” from the beginning of all of the files, and I also renamed to Likewise I renamed to The main goal with the name changes is to make the first character or few unique. I’m a shitty typist to begin with, so being able to type b(tab) and get is a lot easier than having to type out all of the time… and I have to type those things a lot when I’m in full-on coding mode :)

As for the future of the other HBlink programs – some of that is going to be dependent on community support. I would love to see someone step up and port and to Python3. I will eventually get to them, but not soon because….

The master branch of HBlink3 is stable and has been running on the K0USY Group’s “KS-DMR” network all week. On our particular system, with the things we have configured, just moving to Python3 (ok, a few bits of refactoring as well) has given us a 15-20% performance boost (measured in time between packet ingress and processing completion). You will also notice another branch of HBlink3 called uvloop. With this branch I’m swapping out the venerable Twisted module for Python3’s built-in Asyncio module, and a “drop in replacement” for portions of it called uvLoop, an ultra-fast drop-in replacement for parts of Asyncio… just moving to Python3 gave us a nice bump. My hope is that the move to uvloop makes HBlink work much faster – potentially rivaling statically compiled to machine-code software.

I’ve already moved off of the master branch to work on the uvloop branch. This development will be rapid – because the goal is to have and working on uvloop ASAP. Once that is completed, I will go back and start filling in the gaps as well as adding features. I do not intend to back-port new features to the Python2 versions.

The HBlink3 master branch will support the existing python2 hbmonitor software. The uvloop branch will not. I intend to “burn down” the reporting “stuff” and start over with HBlink3 on uvloop. I am looking for javascript (and related browser code) developers to help with this. Hbmonitor is a bandwidth HOG. It renders the entirety of the HTML tables on the server for every incremental change, and pushes all of that HTML out to the browser. A busy system on HBmonitor can use close to 1Mbps of bandwidth for a single browser connected. The goal is to send much less information to the browser, and let the browser build the tables… but I don’t have a clue about programming that stuff. Co-developers welcome!!!

0x49 DE N0MJS

Cort Buffington

Cort Buffington

Join to automatically receive all group messages.