On Jan 21, 2019, at 3:31 PM, n4nqv@... wrote:

I just migrated our group's server to hblink3 a couple days ago (using bridge.py now in place of the old confbridge). Everything seems to be working well at the moment. We're currently using HBmonitor as well, though we'll have to figure something else out when we migrate to the asyncio version. I have a few questions/topics of discussion about the python3/hblink3 migration:

1) I noticed a commit on a branch of HBlink a couple weeks ago fixing an LC generation bug for OpenBridge connections where there's also a TG translation. We do this in our current setup, and had issues with the old HBlink(2) not sending all voice traffic properly via OpenBridge. I never got to the bottom of what the issue actually was, but I suspect it had to to with the outbound voice traffic having the wrong TG number.  UDP packet logs showed the voice traffic getting sent to Brandmeister, but I never dumped the actual packet contents when we were having issues, so I can't verify.

Do you know whether this commit actually fixed the bug, and will a patch be made to hblink3 as well? Didn't look like it had been made the last time I glanced at the source.

The bug was found when I was porting the initial commits of bridge.py, so it actually was “fixed” there before bridge.py in hblink3 ever worked. We’ve verified on the local system that the odd one-way traffic on a BM group that had plagued us for some time is resolved!

2) What needs to be done to get the asyncio version of hblink3 to a usable point? I'm definitely interested in getting migrated over to asyncio soon. I'm developing a few cool new features for our repeaters that rely heavily on HBlink (and some user presence/private call routing additions), and the asyncio version will make it a lot simpler for me to develop in. 

It’s very, very close. I have a version I need to actually try and chase bugs on. I expect very few at this point, but I need to get some more reporting of errors in the callbacks on asyncio so that the problems don’t just quietly happen without a traceback. Next time I have about 2 hours to work and use the KS-DMR network as my testbed, it should be good to go.

3) I also started a project for a monitoring system recently, one that ties into MMDVMHost to send JSON formatted repeater status messages (transmit status, last call info, etc) from all our repeaters to a central MQTT broker, where it's aggregated, logged, and (eventually will be) distributed to browsers. Sounds like it's right up the alley of how the new HBmonitor replacement is going to work. I wouldn't mind helping out with some of the software development. 

I would LOVE to hand off the monitor stuff to someone else. I mostly built the hbmonitor to demonstrate some of my ideas about how a monitor app might look. It’s simple, and could be much more – drill-downs, etc. ANYONE willing to pick up the torch on that will see me working extra hard to standardize what HBlink & friends uses as an output format, etc.

Since it looks like you have experience with asyncio….. any guesses why Uvloop performed like absolute crap, but asyncio kicked butt like it was supposed to?

Thanks for the comments and well worded questions, Spencer.

0x49 DE N0MJS

Thanks,

Spencer Fowler

N4NQV

--

Cort Buffington

H: +1-785-813-1501

M: +1-785-865-7206