Actually, no. See my reply for wat is going on and how to resolve.

Ok...now we are getting somewhere. Please explain the same bm ID on more than one device. What i have here is a cloud server which is an asl to dmr bridge. The dmr hotspot number is unique...so

Have a search back in the list, it was well discussed recently. I believe it relates to using the sam id on more devices so BM anti loopback kicks in. Sent from Outlook From: main@DVSwitch.groups.io

it means that the BrandMeister loop detector thinks you are looping the TG and is trying to protect the network. In Analog_Bridge.ini in the [AMBE_Audio] stanza: Change: minTxTimeMS =

According to Corey, he thinks the audio is saying "blocked"...so what does Blocked mean?

What does it mean if I keep getting a repeated failed connection to the master server? I set up an ASL to DMR Bridge. Sometimes it works for days, and then suddenly it will refuse to maintain a

Ok, I’m going to admit to having not looked at any of this for a long time. I've found a few discrepancies in what I’ve done over time I have a question that needs answered by the stewards of HB

Hi Cort, Understood on the muddling of OSI layers - I get where you're coming from. I think the easiest work around in that case is an option to rewrite the RADIO_ID for frames being sent to a

Yes, client side validation was made option with loose (thanks again for that) You’re now using network layer information to authenticate the application layer. Yes, it will work. I’m reluctant

Nobody knows for sure what the limit is but i think you are over hopeful on that many streams. Many things dependent in other things running in memory. I would not 'count-on' more than 12 streams.

Does raspberry pi 3 B+ have enough computing power to be a hub/bridge that can handle 20 to 50 connected nodes? Thanks very much guys for your support 73 Dennis

To clarify, does this refer to removing the validation for the source "RADIO_ID" sent in a frame from client -> master? If yes, I gave this some thought a while ago, and the conclusion I came to was

For me, hands down, ability for a single hblink.py master to “network” a group of repeaters tied to it.

I think just as we have IPSC_Bridge and HB_Bridge, I think OpenBridge_Bridge would be the way to go. (Well except for the name). Steve

Removing source validation from hblink.py master probably won’t work because of hblink.py master’s a ability to repeat back to a group of connected clients. These two features will have to be

OpenBridge is based on home-brew repeater protocol… so going through IPSC_Bridge to HB_Bridge would be the appropriate way to use it. Pushing it into DMRlink would mean full protocol translation in

That sounds interesting! Would the same code be able to able to be ported to DMRlink? Be nice to have a more open way to trunk it to a bigger network. 73, Peter Sent from Outlook From:

parrot.py dones’t hae a choice, because if it’s a master, it’s hblink.py underneath that’s doing it. The work is not hard… the consequences of the choice are. I’ll work on this in the next

OpenBridge is a work on progress for me. Not working yet, so not pushed to the hblink repo. -- Cort Buffington H: +1-785-813-1501 M: +1-785-865-7206

Hi All, I'm curious if anyone has experimented with forwarding GPS / SMS data from a hblink application to an external master for additional processing? Also, does anyone know if GPS messages are