HBLink Summer of Code (unofficial) #hblink


Randy AA6RH
 

Hi Everyone,

I wanted to plant a seed in everyone's head. I'm starting to plan out what the summer will involve for me. I'm taking a serious look at the code for HBLink3 and have the feeling that it needs.... something.

HBLink was built as a tool bench for interconnection of DMR networks, and the lead developer who built it from scratch as a way to learn Python has moved on. It is now mostly a framework on which talented and motivated individuals or small teams can build applications that do a variety of "stuff" with the DMR data packets that arrive via a combination of Peer and OpenBridge connections. Also, HBLink can even behave like a peer to a master DMR server and process traffic that way (though there can be significant problems with network admins when you attempt to do this -- YMMV).

The default functionality of the main program does almost nothing at all except set everything up and then pass all traffic between peers. Unlocking the potential of this software requires using one of the apps that build on the base functionality. Everything right now is one-off in nature.

The question I pose is this: "do we like that it is built this way, or can/should we improve it?"

I know we have individuals and small teams working on cool extensions for processing and gating GPS data to APRS (at least APRS-IS), but is it something where we want that function to be a built-in? Do we want the built-in apps (bridge.py, playback.py, and the like) to be integrated like plugins that extend a single server, or do we like the one-app-per-port approach and just use UDP to tie components together?

It definitely feels like this summer could be spent not only rethinking this platform, but re-engineering it to be considerably more robust, with 100% fewer memory leaks at the very least.

So, I'd like to hear what you all are interested in seeing happen here. I legitimately want this tool to be useful.

--R 
--
Randy Hall AA6RH (not K7AGE, quit asking) 😁


Sérgio PU5SMS
 

Hello Randy and everyone ...
I have been talking and collaborating a lot with a hblink3 branch conducted by KF7EEL and that contains the GPS and the plot in aprs.fi as a target. We have obtained much fruit from these efforts. Here in southern Brazil we have been using HBlink3 as a DMR master server for a small network that today has 18 repeaters and 20 connected hotspots. I would like to see a dns module implemented in hblink3 ... this would enable us to offer colleagues who connect to our master a fixed address for their repeaters and also organize the network better, so all repeaters would have a default address ... I don't I see so much difficulty in achieving this, although I am not able to do it, since the hbmonitor itself shows the original and current IP addresses of each one ... it would take these addresses and route to the server's fixed address ... it also allows you to make a publicity page available to the repeater ... well it's just an idea ... I don't feel able to do that, but I think it would be useful and make everything more practical for fellow users and those that keeps the repeaters.

Congratulations on the work you have done and also to all the other collaborators ...

73's!

PU5SMS - SAEZ


Em sáb., 6 de fev. de 2021 às 04:09, Randy AA6RH <aa6rh@...> escreveu:

Hi Everyone,

I wanted to plant a seed in everyone's head. I'm starting to plan out what the summer will involve for me. I'm taking a serious look at the code for HBLink3 and have the feeling that it needs.... something.

HBLink was built as a tool bench for interconnection of DMR networks, and the lead developer who built it from scratch as a way to learn Python has moved on. It is now mostly a framework on which talented and motivated individuals or small teams can build applications that do a variety of "stuff" with the DMR data packets that arrive via a combination of Peer and OpenBridge connections. Also, HBLink can even behave like a peer to a master DMR server and process traffic that way (though there can be significant problems with network admins when you attempt to do this -- YMMV).

The default functionality of the main program does almost nothing at all except set everything up and then pass all traffic between peers. Unlocking the potential of this software requires using one of the apps that build on the base functionality. Everything right now is one-off in nature.

The question I pose is this: "do we like that it is built this way, or can/should we improve it?"

I know we have individuals and small teams working on cool extensions for processing and gating GPS data to APRS (at least APRS-IS), but is it something where we want that function to be a built-in? Do we want the built-in apps (bridge.py, playback.py, and the like) to be integrated like plugins that extend a single server, or do we like the one-app-per-port approach and just use UDP to tie components together?

It definitely feels like this summer could be spent not only rethinking this platform, but re-engineering it to be considerably more robust, with 100% fewer memory leaks at the very least.

So, I'd like to hear what you all are interested in seeing happen here. I legitimately want this tool to be useful.

--R 
--
Randy Hall AA6RH (not K7AGE, quit asking) 😁


--
PU5SMS - Saez
South of Bazil


Simon
 

On 06/02/2021 07:09, Randy AA6RH wrote:
Hi Everyone,

I wanted to plant a seed in everyone's head. I'm starting to plan out
what the summer will involve for me. I'm taking a serious look at the
code for HBLink3 and have the feeling that it needs.... something.
HI Randy et al

Well, what can I say. I have been working in a similar direction with my
fork of HBLink. We call it FreeDMR. (It's on Github) and we've extended
this and started building a network with it (http://freedmr.uk), so I
agree with your ideas.

73


Simon - G7RZU


Matthew 2E0SIP
 

Do we want the built-in apps (bridge.py, playback.py, and the like) to be integrated like plugins that extend a single server, or do we like the one-app-per-port approach and just use UDP to tie components together?
The core routing engine should be kept as lean and as light as possible, otherwise you will hit scaling problems on larger systems.

That said, the applications could potentially announce themselves via some form of auto-discovery process to avoid the complications of mapping ports in each direction and avoiding clashes.



Cheers


thlongan@...
 

I am new and trying to understand how everything fits together and how it works. I would like to be pointed to some documentation on HBlink.

I appreciate everything you are doing, and look forward to your upgrades.

Thank you.



Sent from my Verizon, Samsung Galaxy smartphone


-------- Original message --------
From: Randy AA6RH <aa6rh@...>
Date: 2/6/21 2:09 AM (GMT-05:00)
To: HBlink@DVSwitch.groups.io
Subject: [Special] [HBlink] HBLink Summer of Code (unofficial) #hblink

Hi Everyone,

I wanted to plant a seed in everyone's head. I'm starting to plan out what the summer will involve for me. I'm taking a serious look at the code for HBLink3 and have the feeling that it needs.... something.

HBLink was built as a tool bench for interconnection of DMR networks, and the lead developer who built it from scratch as a way to learn Python has moved on. It is now mostly a framework on which talented and motivated individuals or small teams can build applications that do a variety of "stuff" with the DMR data packets that arrive via a combination of Peer and OpenBridge connections. Also, HBLink can even behave like a peer to a master DMR server and process traffic that way (though there can be significant problems with network admins when you attempt to do this -- YMMV).

The default functionality of the main program does almost nothing at all except set everything up and then pass all traffic between peers. Unlocking the potential of this software requires using one of the apps that build on the base functionality. Everything right now is one-off in nature.

The question I pose is this: "do we like that it is built this way, or can/should we improve it?"

I know we have individuals and small teams working on cool extensions for processing and gating GPS data to APRS (at least APRS-IS), but is it something where we want that function to be a built-in? Do we want the built-in apps (bridge.py, playback.py, and the like) to be integrated like plugins that extend a single server, or do we like the one-app-per-port approach and just use UDP to tie components together?

It definitely feels like this summer could be spent not only rethinking this platform, but re-engineering it to be considerably more robust, with 100% fewer memory leaks at the very least.

So, I'd like to hear what you all are interested in seeing happen here. I legitimately want this tool to be useful.

--R 
--
Randy Hall AA6RH (not K7AGE, quit asking) 😁


Jon K1IMD
 

test

On 2/6/2021 02:09, Randy AA6RH wrote:
Hi Everyone,

I wanted to plant a seed in everyone's head. I'm starting to plan out what the summer will involve for me. I'm taking a serious look at the code for HBLink3 and have the feeling that it needs.... something.

HBLink was built as a tool bench for interconnection of DMR networks, and the lead developer who built it from scratch as a way to learn Python has moved on. It is now mostly a framework on which talented and motivated individuals or small teams can build applications that do a variety of "stuff" with the DMR data packets that arrive via a combination of Peer and OpenBridge connections. Also, HBLink can even behave like a peer to a master DMR server and process traffic that way (though there can be significant problems with network admins when you attempt to do this -- YMMV).

The default functionality of the main program does almost nothing at all except set everything up and then pass all traffic between peers. Unlocking the potential of this software requires using one of the apps that build on the base functionality. Everything right now is one-off in nature.

The question I pose is this: "do we like that it is built this way, or can/should we improve it?"

I know we have individuals and small teams working on cool extensions for processing and gating GPS data to APRS (at least APRS-IS), but is it something where we want that function to be a built-in? Do we want the built-in apps (bridge.py, playback.py, and the like) to be integrated like plugins that extend a single server, or do we like the one-app-per-port approach and just use UDP to tie components together?

It definitely feels like this summer could be spent not only rethinking this platform, but re-engineering it to be considerably more robust, with 100% fewer memory leaks at the very least.

So, I'd like to hear what you all are interested in seeing happen here. I legitimately want this tool to be useful.

--R 
--
Randy Hall AA6RH (not K7AGE, quit asking) 😁


Randy AA6RH
 

Test passed
--
Randy Hall AA6RH (not K7AGE, quit asking) 😁


Randy AA6RH
 

On Sat, Feb 6, 2021 at 10:11 AM, <thlongan@...> wrote:
I am new and trying to understand how everything fits together and how it works. I would like to be pointed to some documentation on HBlink.

I started out here trying to document HBLink in the wiki. I encourage everyone to read and contribute as best they can to the wiki. It can definitely help you start to understand how it all works.

All that said, nothing substitutes for being able to read the code and make sense of it.

I'd even be interested in seeing some forks of the code be brought in as development branches, but I think I need to get a better sense of how to manage any changes and arrange a proper release schedule.

--R
--
Randy Hall AA6RH (not K7AGE, quit asking) 😁


Jon K1IMD
 

Sorry for the test msg but  got a bounce from my ISP and in the process lost my detailed and lengthy response. :(

Andy,
I have been using hblink for several years.  My use is to facilitate several of my mmdvm repeaters to connect to c-Bridges.  I also use the same bridging technics to support hotspots from time to time.  Using IPSC_Bridge<->HB_Bridge and occasionally I add hblink3 in the chain IPSC_Bridge<->HB_Bridge<->hblink3 to accomplish this.

My use of hblink may be different than much of this group because I still wish to maintain support for IPSC networks, and am not trying to build a stand alone hblink network.  Having support to connect to other networks is a good thing.  Since my systems are primarily repeaters there is no network hopping.  APRS reporting is pretty slick but not allowed on some networks but might be nice to have  "switch" to turn it on or off, same goes for Private Call.

What is important to me is as we go forward with new features we don't lose features of the past.
Features/Support that is important to me:
- Maintaining support for IPSC_Bridge (IPSC Networks), perhaps IPSC_Bridge<->hblink3
- * Support for Private Call/Alerts passing through to IPSC_Bridge
- Support for talkback (Group & Private Calls) the also pass through to IPSC_Bridge to allow a parrot support on a bridge
- * Support for text messaging to also pass through IPSC_Bridge

* I understand that this may not be possible due to each manufacturers proprietary implementation

My 2 cents

73
K1IMD

On 2/6/2021 13:42, Jon K1IMD wrote:
test

On 2/6/2021 02:09, Randy AA6RH wrote:
Hi Everyone,

I wanted to plant a seed in everyone's head. I'm starting to plan out what the summer will involve for me. I'm taking a serious look at the code for HBLink3 and have the feeling that it needs.... something.

HBLink was built as a tool bench for interconnection of DMR networks, and the lead developer who built it from scratch as a way to learn Python has moved on. It is now mostly a framework on which talented and motivated individuals or small teams can build applications that do a variety of "stuff" with the DMR data packets that arrive via a combination of Peer and OpenBridge connections. Also, HBLink can even behave like a peer to a master DMR server and process traffic that way (though there can be significant problems with network admins when you attempt to do this -- YMMV).

The default functionality of the main program does almost nothing at all except set everything up and then pass all traffic between peers. Unlocking the potential of this software requires using one of the apps that build on the base functionality. Everything right now is one-off in nature.

The question I pose is this: "do we like that it is built this way, or can/should we improve it?"

I know we have individuals and small teams working on cool extensions for processing and gating GPS data to APRS (at least APRS-IS), but is it something where we want that function to be a built-in? Do we want the built-in apps (bridge.py, playback.py, and the like) to be integrated like plugins that extend a single server, or do we like the one-app-per-port approach and just use UDP to tie components together?

It definitely feels like this summer could be spent not only rethinking this platform, but re-engineering it to be considerably more robust, with 100% fewer memory leaks at the very least.

So, I'd like to hear what you all are interested in seeing happen here. I legitimately want this tool to be useful.

--R 
--
Randy Hall AA6RH (not K7AGE, quit asking) 😁



Eric - KF7EEL
 

I like where this is going.

In the last day or so, I have been experimenting with combining the GPS/Data application and Echo into bridge.py to make it run as an "all included" application.  So far, it has been working, still testing the scalability and performance. This is also in preparation for allowing HBLink to create and send SMS messages. This would eliminate some configuration and make it easier to setup. Slowly making progress with a function to create and send SMS from HBlink. This would open the door to a 2 way APRS message gateway, 2 way email, 2 way whatever you can think of, and possibly Motorola ARS stuff. We will see where this goes as it is a TON of work to go from a string of text to a correctly formatted sequence of DMR packets encapsulated in MMDVM.


Sérgio PU5SMS
 

Simon, what address is Git on your Fork?

PU5SMS - SAEZ


Em sáb., 6 de fev. de 2021 às 13:25, Simon via groups.io <simon=gb7fr.org.uk@groups.io> escreveu:

On 06/02/2021 07:09, Randy AA6RH wrote:
> Hi Everyone,
>
> I wanted to plant a seed in everyone's head. I'm starting to plan out
> what the summer will involve for me. I'm taking a serious look at the
> code for HBLink3 and have the feeling that it needs.... something.

HI Randy et al

Well, what can I say. I have been working in a similar direction with my
fork of HBLink. We call it FreeDMR. (It's on Github) and we've extended
this and started building a network with it (http://freedmr.uk), so I
agree with your ideas.

73


Simon - G7RZU








--
PU5SMS - Saez
South of Bazil


Sérgio PU5SMS
 

Simon, what's Git address of your HBlink3 fork?

PU5SMS - SAEZ


Em sáb., 6 de fev. de 2021 às 20:42, Sérgio M. S. Saez <pu5sms.saez@...> escreveu:

Simon, what address is Git on your Fork?

PU5SMS - SAEZ


Em sáb., 6 de fev. de 2021 às 13:25, Simon via groups.io <simon=gb7fr.org.uk@groups.io> escreveu:
On 06/02/2021 07:09, Randy AA6RH wrote:
> Hi Everyone,
>
> I wanted to plant a seed in everyone's head. I'm starting to plan out
> what the summer will involve for me. I'm taking a serious look at the
> code for HBLink3 and have the feeling that it needs.... something.

HI Randy et al

Well, what can I say. I have been working in a similar direction with my
fork of HBLink. We call it FreeDMR. (It's on Github) and we've extended
this and started building a network with it (http://freedmr.uk), so I
agree with your ideas.

73


Simon - G7RZU








--
PU5SMS - Saez
South of Bazil


Randy AA6RH
 

I would imagine this is the repo Simon referred to:

https://github.com/hacknix/FreeDMR

FWIW, I am enthusiastic that there are innovative forks of the code here. I think that's part of what makes it a better project.

--R
--
Randy Hall AA6RH (not K7AGE, quit asking) 😁


Randy AA6RH
 

A few additional thoughts to put out there:

  • HBLink3 needs a proper plugin architecture. That is, the core functionality should be done as a library that doesn't necessarily do more than just launch the service and, depending on what plugins are available as installed packages (think Python Packages), will extend the function of the core library in order to get things done.
  • IPSC_Bridge needs to be updated to Python 3.x. That's actually perhaps more pressing than doing an update to HBLink3. I believe that Steve N4IRS is still using it for bridging IPSC to other things via the Analog_Bridge portion of DVSwitch.
  • I think we can decommission HB_Bridge without updating it to Python 3.x, since (again) Steve N4IRS has built something in the main DVSwitch arsenal to accomplish that function.

But I get the feeling the key thing needed is a pluggable architecture that lets individuals extend the core function of HBLink without having to fork the whole code base and hack away.

I also think there needs to be some amount of built-in features that mimic or approach the function of well-known networks. Such as adding the one-master-per-peer approach that BM uses, or the default talk group reflector behavior like you see in DMR+.

After that, it could be adding plugins to do things like parrot, APRS/GPS, text messaging, DMR as packet radio, etc. and the sky's the limit.

Might as well dream big if we're going to dream here.

--R

--
Randy Hall AA6RH (not K7AGE, quit asking) 😁


W Paul Mills AC0HY
 

Comments below

On 2/6/21 6:59 PM, Randy AA6RH wrote:
A few additional thoughts to put out there:

  • HBLink3 needs a proper plugin architecture. That is, the core functionality should be done as a library that doesn't necessarily do more than just launch the service and, depending on what plugins are available as installed packages (think Python Packages), will extend the function of the core library in order to get things done.
Fully agree as to a proper plugin arch.
  • IPSC_Bridge needs to be updated to Python 3.x. That's actually perhaps more pressing than doing an update to HBLink3. I believe that Steve N4IRS is still using it for bridging IPSC to other things via the Analog_Bridge portion of DVSwitch.
Again I agree fully. This really makes things overly complicated in it's present form
  • I think we can decommission HB_Bridge without updating it to Python 3.x, since (again) Steve N4IRS has built something in the main DVSwitch arsenal to accomplish that function.
Had not noticed or explored this, but sounds like it would make things much simpler.

But I get the feeling the key thing needed is a pluggable architecture that lets individuals extend the core function of HBLink without having to fork the whole code base and hack away.

I also think there needs to be some amount of built-in features that mimic or approach the function of well-known networks. Such as adding the one-master-per-peer approach that BM uses, or the default talk group reflector behavior like you see in DMR+.

After that, it could be adding plugins to do things like parrot, APRS/GPS, text messaging, DMR as packet radio, etc. and the sky's the limit.

Might as well dream big if we're going to dream here.

Anything done to make an initial first time use a little easier would also be a plus. The initial startup is a bit challenging, after that, not so bad. And a second deployment probably not to bad now that I know the basic concept.
--R

--
Randy Hall AA6RH (not K7AGE, quit asking) 😁


-- 
/**************************************************
* Amateur Radio Station AC0HY                     *
* W. Paul Mills         SN807                     *
* Assistant EC Alpha-1 ARES Shawnee/Wabaunsee, KS *
* President Kaw Valley Amateur Radio Club         *
**************************************************/


Simon
 

On 07/02/2021 00:48, Randy AA6RH wrote:
I would imagine this is the repo Simon referred to:

https://github.com/hacknix/FreeDMR <https://github.com/hacknix/FreeDMR>

FWIW, I am enthusiastic that there are innovative forks of the code
here. I think that's part of what makes it a better project.

Thanks for posting the link and your words of support Randy :-)


Simon


Jorge (George)
 

Free......

 

What kind off free is that???

When I try to use my own group, if is not included on bridge, not work!

You think this is a synonym for "Free".

 

Free = I use whatever I want without having to ask anyone, without knowledge of sysop or anyone else. Use whatever I and a group of friends want as our group without having to pass that information on to the "owner of the network"

 

This is freedmr this is CAOS.
 


Randy AA6RH
 

That's an interesting take. I agree that "free" as in "freedom" versus "free" as in "beer" is a healthy distinction to make.

But "free" doesn't also mean you can interconnect to someone else's network without "playing nice". I've always held that my freedom ends where it intersects with the freedom of others. So, in that spirit, I don't think FreeDMR == Chaos. People need to communicate with each other and come to a mutually beneficial agreement before proceeding with interconnecting. Some random ham going in and connecting things because "screw you, I can do what I want" is precisely how HBLink came to be something of a pariah in DMR network circles.

--R
--
Randy Hall AA6RH (not K7AGE, quit asking) 😁


Randy AA6RH
 

And to soften the overall message here, I would add the following:

It's equally likely that the random ham goes in and connects things because they don't understand what they're doing. The connection of networks is something to take seriously, starting with:

  • Does the network operator/owner WANT to be interconnected with anyone else?
  • Is the "random ham" certain that there are no existing interconnections that might accomplish what they want to do?
  • Is there a process by which that ham can start the conversation about interconnection?

If the answer to any of those questions is "no", then perhaps interconnecting networks and modes isn't the right thing to do at that time. More investigation and communication with the people involved and invested in those networks should happen first.

And if you're really itching to play with this stuff, start with buying a couple hotspots and connecting them together using your own HBLink master server or other network. You can mock up a pretty basic network using two or three hotspots and a few digital radios (that you might even borrow in case you don't have the gear on hand).

--R
--
Randy Hall AA6RH (not K7AGE, quit asking) 😁


Simon
 

On 08/02/2021 16:55, Randy AA6RH wrote:
And to soften the overall message here, I would add the following:
<snip>

Thanks for the thoughtful comments Randy. I agree with you. I see
communication and education as key elements of our hobby. I also often
say, "we just have one rule, be nice". I see someone doing something we
may see as "wrong" not as an opportunity for criticism but as an
opportunity for communication and education. Since working with DMR I
haver made many friends worldwide and that's a good thing.

Jorge, I am not sure quite what you are getting at? Are you advocating
or criticising the work I and others have done over the last few months?
If you'd like to discuss it further, please feel free to contact me or
our group directly. Either way in one sense it doesn't matter, we are
both free to do what we wish and to form our own opinions and you know
what, if we agree that's good, if we disagree that's good too.
Disagreement is healthy. It drives innovation.

I have used the word free as it is commonly used in Open Source circles
- Free as in Speech and Free as in Beer.

The freedom is to use, modify and distribute software as you see fit
(provided the original work is correctly attributed)

Also, it should remain free to use and people should not be charged for
it's use.

Remember these freedoms apply to the *software*, which is what we are
discussing.

And lastly, to quote the HBLink documentation - software "doesn't build
networks, people do".

Regards

Simon - G7RZU