Date   

Re: metadata management

Patrick Perdue
 

Yes, that's what I was referring to. I don't know what the process is for having your reflector listed, only that it can be done.

On 11/26/2020 4:22 PM, Tony Langdon wrote:
On 27/11/20 8:20 am, Patrick Perdue wrote:
As I understand it, you can set up a private P25 reflector which is
available to anyone who uses the pi-star host files, thus, no need to
link to a public reflector. This is what I plan to do. I will probably
also get zero users, but at least I know that coming in.
You can do that, or you can setup your own public reflector.  You just
have to ask to get it listed in the public P25Hosts file.  I did this
for 50535.


Re: metadata management

 

On 27/11/20 8:20 am, Patrick Perdue wrote:

As I understand it, you can set up a private P25 reflector which is
available to anyone who uses the pi-star host files, thus, no need to
link to a public reflector. This is what I plan to do. I will probably
also get zero users, but at least I know that coming in.
You can do that, or you can setup your own public reflector.  You just
have to ask to get it listed in the public P25Hosts file.  I did this
for 50535.

--
73 de Tony VK3JED/VK3IRL
http://vkradio.com


Re: metadata management

Patrick Perdue
 

As I understand it, you can set up a private P25 reflector which is available to anyone who uses the pi-star host files, thus, no need to link to a public reflector. This is what I plan to do. I will probably also get zero users, but at least I know that coming in.


On 11/26/2020 1:42 PM, k7wby@... wrote:
Here's a bit of advice, take it for what it's worth. 
If you're thinking of linking your other modes to a currently active P25 Reflector, don't. You will be chastised to no end and probably banned from that reflector for life.

The only solution you have is a P25Gateway and P25Reflector with a private TG. I did that for a while and had 0 users. I provided instructions on how to update the P25Hosts.txt files on their hotspots but I guess that was more work than they wanted to do. In the end I took down the reflector and gateway and just told them to use their hotspots in P252DMR mode and connect to my XLX reflector. I have a interlink to BM3103 on the XLX. Now I have P25 users and the meta data is not an issue.


Re: metadata management

 

On 27/11/20 5:42 am, k7wby@arrl.net wrote:
Here's a bit of advice, take it for what it's worth. 
If you're thinking of linking your other modes to a currently active
P25 Reflector, don't. You will be chastised to no end and probably
banned from that reflector for life.
I setup my own P25 reflector for my DVSwitch system to connect to, so I
wouldn't upset anyone else.  Got it registered and it can be reached by
any hotspot with up to date hosts files.

The only solution you have is a P25Gateway and P25Reflector with a
private TG. I did that for a while and had 0 users. I provided
instructions on how to update the P25Hosts.txt files on their hotspots
but I guess that was
Or do as I did and get G4KLX to put your reflector into the public hosts
file.  Just takes a "feature request" in the right Git repository.
more work than they wanted to do. In the end I took down the reflector
and gateway and just told them to use their hotspots in P252DMR mode
and connect to my XLX reflector. I have a interlink to BM3103 on the
XLX. Now I have P25 users and the meta data is not an issue.
Hmm P252DMR - that sounds like it would only work on an OpenSpot 3. 
This isn't possible on a Pi-Star based hotspot, because it requires
transcoding.

--
73 de Tony VK3JED/VK3IRL
http://vkradio.com


Re: metadata management

 

On 26/11/20 11:51 am, Steve N4IRS wrote:
So,
you have D-Star, DMR and AllStar.
If you used AllStar to mix you could keep the number of vocoders to
two and only have one transcoder. For the audio, you would have 2
private nodes. The first node would be DMR and pointed at TGIF. The
second node would be D-Star and pointed at XLX.  As you said in your
first message, you issue would then be metadata.
This is where my system is at.  I have it arranged around an instance of
AllStar (except for DMR - YSF, which uses its own instance of
MMDVM_Bridge, and no transcoding).  Audio wise, my system works well and
maintains good quality (because I transcode as few times as possible,
regardless of path), but it would be nice to have a way of passing
metadata "around" AllStar when going between digital modes that are
using different vocoders, without handling audio, to account for cases
like mine.

--
73 de Tony VK3JED/VK3IRL
http://vkradio.com


Re: metadata management

k7wby@...
 

Here's a bit of advice, take it for what it's worth. 
If you're thinking of linking your other modes to a currently active P25 Reflector, don't. You will be chastised to no end and probably banned from that reflector for life.

The only solution you have is a P25Gateway and P25Reflector with a private TG. I did that for a while and had 0 users. I provided instructions on how to update the P25Hosts.txt files on their hotspots but I guess that was more work than they wanted to do. In the end I took down the reflector and gateway and just told them to use their hotspots in P252DMR mode and connect to my XLX reflector. I have a interlink to BM3103 on the XLX. Now I have P25 users and the meta data is not an issue.


Re: Security password on Brandmeister

Patrick Perdue
 

You only need to change the

password=passw0rd

line in the [DMR Network] stanza of MMDVM_Bridge.ini for any DVSwitch instance, replacing it with the hotspot security password you've set up on the Brandmeister self-care dashboard.

AFAIK, this change doesn't affect repeater ID's yet, just personal CCS7.

So, you shouldn't need to make any changes to your MMDVM repeater at this time, assuming you are using a six digit repeater ID.


On 11/25/2020 11:14 PM, Steve - WB8GRS wrote:

I read elsewhere that Brandmeister Hotspot Users must configure hotspot security password to continue using Brandmeister.  This affect masters 3101, 3102 and 3103 and I assume many other masters. This starts to take affect on Nov 30, 2020.  I have both an Android to DMR and Allstar to DMR bridges running as well as a couple DMR hotspots and a MMDVM DMR repeater on Brandmeister..  Do I need to add a security password to my Android to DMR bridge that I use with DV Switch and to my Allstar to DMR bridge in order to stay logged into Brandmeister, and if yes, how do I do that?

If I need to ask this in a subgroup, please let me know which one.

Thanks,
73,
Steve_WB8GRS


Security password on Brandmeister

Steve - WB8GRS
 

I read elsewhere that Brandmeister Hotspot Users must configure hotspot security password to continue using Brandmeister.  This affect masters 3101, 3102 and 3103 and I assume many other masters. This starts to take affect on Nov 30, 2020.  I have both an Android to DMR and Allstar to DMR bridges running as well as a couple DMR hotspots and a MMDVM DMR repeater on Brandmeister..  Do I need to add a security password to my Android to DMR bridge that I use with DV Switch and to my Allstar to DMR bridge in order to stay logged into Brandmeister, and if yes, how do I do that?

If I need to ask this in a subgroup, please let me know which one.

Thanks,
73,
Steve_WB8GRS


Re: Towards open-source infrastructure for DMR repost from OpenDV

Randy AA6RH
 

G4KLX is saying what I've been thinking for at least a year now. The fact that BM and to a lesser extent DMR-MARC, DCI, TGIF and others have created a closed-source, walled-garden approach to interlinking leaves the individual repeater operators at the relative mercy of these networks. The recent UK master server crash is a clear indicator that the centralized technique needs some refactoring.

It's not original, sadly. Other analog-based interlinking tech has the same problems (I'm looking at IRLP and AllStarLink as two easy examples). Hams generally like the interconnection to be plug-and-play. A new approach would require people to actually do things like RTFM and test their changes in isolation before unleashing it on the network, possibly wreaking havoc.

I'm all for an open and decentralized approach to interlinking. The obvious downsides is that it moves more of the work to the repeater operators to be on the lookout for bad actors, or at least LIDS. Some of what I'm getting at is that there needs to be tools to help a sysop/control op check that their configuration changes are going to do what they think it will. That's a tall order.

I'd say that philosophically speaking, HBLink is aligned with this particular view of interlinking and interconnection. I think we have some real architectural challenges (not to mention devops, developer community, and all the rest) to become a robust contributor to this new approach. I also think that IPSC_Bridge and HB_Bridge (to a lesser extent) need to be brought up-to-date to Python 3 through a focus on creating a testable code base and then evolving it from there.

I love this manifesto. I hope we can build something from it.

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


Re: metadata management

Patrick Perdue
 

OK, so things are pretty much as I thought they were. Just wanted to make sure I wasn't missing anything should I decide to redesign this system. I'll probably keep things as-is for now, then add another private node for P25.

Thanks.

On 11/25/2020 7:51 PM, Steve N4IRS wrote:
So,
you have D-Star, DMR and AllStar.
If you used AllStar to mix you could keep the number of vocoders to two and only have one transcoder. For the audio, you would have 2 private nodes. The first node would be DMR and pointed at TGIF. The second node would be D-Star and pointed at XLX.  As you said in your first message, you issue would then be metadata.

Steve


On 11/25/20 7:32 PM, Patrick Perdue wrote:
I'm not great at writing out flows.

My setup currently doesn't use ircDDBGateway, since that's all handled at the XLX reflector end. So, it goes like this.

Allstar <-> AB <-> HBLink <-> MB <-> XLXD (DMR, since XLX is also handling a BM interlink and YSF traffic) <-> ambed (connected to the XLX reflector) <-> TGIF.

I'm sure I screwed that up.

So basically, native AMBE traffic is transcoded to analog using the MD380-emu vocoder back to Allstar. DStar is transcoded through the pair of ThumnDV's on the reflector, which is then sent to MD380emu and then Allstar. Between DMR or YSF and DStar, this is fine, but from Allstar to DStar, it's going through another AMBE transcode before A_B sees it, so more latency and lower quality audio.

If I connect to the reflector directly as DStar, then use ASL to connect to the other modes, perhaps on another module of the reflector and HBLink, then DMR-YSF would only see the call specified in A_B, correct?


On 11/25/2020 7:18 PM, Steve N4IRS wrote:
I don't see how there are 2 vocoders to get from AllStar to D-Star. The flow would be:
AllStar <-> AB <-> MB <-> ircDDBGateway <-> XLX for D-Star.
You could drop the ircDDBGateway and go to XLX DMR.

Steve

On 11/25/20 7:14 PM, Patrick Perdue wrote:
Sure, but I'm currently going through two of them to get from Allstar to DStar.

I'm just wondering if there's a way to drop one of them out and still maintain metadata. I could directly connect A_B and MMDVM_Bridge to the XLX reflector and only direct DStar traffic to the module, and audio between DStar and the other digital modes should be about the same as it is now, but audio from Allstar to DStar has one less generation of vocoding, but then I lose metadata between the digital modes. At least, this is how I understand it.


On 11/25/2020 6:55 PM, Steve N4IRS wrote:
Patrick,
Either way, you have to go through a vocoder to go from analog to D-Star Same for P25, you still have to go through a vocoder.

Steve

On 11/25/20 6:28 PM, Patrick Perdue wrote:
Hi:

I have a system that incorporates ASL, XLX, HBLink and DVSwitch. I'm toying with the idea of adding P25.

Currently, DStar is handled by XLX and a pair of transcoders connected to the XLX reflector, not DVSwitch. I would like to connect ASL directly to the XLX reflector in DStar mode, so that the audio to and from DStar to ASL is not transcoded through AMBE, but still pass metadata to DStar from the other digital modes. Is this at all possible? Similar question in regards to P25.

Basically, I want to do the least amount of transcoding possible to and from analog, while maintaining the greatest compatibility across digital modes. What I have now works, but I'd love to get rid of that extra layer of transcoding between analog and DStar without sacrificing metadata.

Thanks.
























Re: pyUC P25 "not linked"

Steve N4IRS
 

You want to add it in 2 places.
Add the reflector TG, IP and port in private_P25Hosts.txt

Add the Name and TG in pyUC.ini in the P25 section.

Steve N4IRS

On 11/25/20 9:45 PM, Scotty 2543G KD2LWH wrote:
It seems to have fixed itself after a few times of opening and closing the application. Now I'm wondering how to add my private reflector to the list on USRP Client for P25. I have added it to the P25Hosts.txt file on the DV_Switch Server, but it doesn't show in the list on the client. Any ideas?


Re: pyUC P25 "not linked"

Mike Zingman - N4IRR
 

The app uses the configuration file pyUC.ini


Re: pyUC P25 "not linked"

Steve N4IRS
 

Add it to pyUC.ini

On 11/25/20 9:45 PM, Scotty 2543G KD2LWH wrote:
It seems to have fixed itself after a few times of opening and closing the application. Now I'm wondering how to add my private reflector to the list on USRP Client for P25. I have added it to the P25Hosts.txt file on the DV_Switch Server, but it doesn't show in the list on the client. Any ideas?


Re: pyUC P25 "not linked"

Scotty 2543G KD2LWH
 

It seems to have fixed itself after a few times of opening and closing the application. Now I'm wondering how to add my private reflector to the list on USRP Client for P25. I have added it to the P25Hosts.txt file on the DV_Switch Server, but it doesn't show in the list on the client. Any ideas?


pyUC P25 "not linked"

Scotty 2543G KD2LWH
 

Hey guys,
The first time I started pyUC and switched modes to P25 it worked, no issues. Everytime after, I try to switch modes and it says "not linked" when I hit P25 and goes back to DMR. Any ideas why? I didn't ever "link or unlink" anything. Thanks in advance.


Re: metadata management

Steve N4IRS
 

So,
you have D-Star, DMR and AllStar.
If you used AllStar to mix you could keep the number of vocoders to two and only have one transcoder. For the audio, you would have 2 private nodes. The first node would be DMR and pointed at TGIF. The second node would be D-Star and pointed at XLX.  As you said in your first message, you issue would then be metadata.

Steve

On 11/25/20 7:32 PM, Patrick Perdue wrote:
I'm not great at writing out flows.

My setup currently doesn't use ircDDBGateway, since that's all handled at the XLX reflector end. So, it goes like this.

Allstar <-> AB <-> HBLink <-> MB <-> XLXD (DMR, since XLX is also handling a BM interlink and YSF traffic) <-> ambed (connected to the XLX reflector) <-> TGIF.

I'm sure I screwed that up.

So basically, native AMBE traffic is transcoded to analog using the MD380-emu vocoder back to Allstar. DStar is transcoded through the pair of ThumnDV's on the reflector, which is then sent to MD380emu and then Allstar. Between DMR or YSF and DStar, this is fine, but from Allstar to DStar, it's going through another AMBE transcode before A_B sees it, so more latency and lower quality audio.

If I connect to the reflector directly as DStar, then use ASL to connect to the other modes, perhaps on another module of the reflector and HBLink, then DMR-YSF would only see the call specified in A_B, correct?


On 11/25/2020 7:18 PM, Steve N4IRS wrote:
I don't see how there are 2 vocoders to get from AllStar to D-Star. The flow would be:
AllStar <-> AB <-> MB <-> ircDDBGateway <-> XLX for D-Star.
You could drop the ircDDBGateway and go to XLX DMR.

Steve

On 11/25/20 7:14 PM, Patrick Perdue wrote:
Sure, but I'm currently going through two of them to get from Allstar to DStar.

I'm just wondering if there's a way to drop one of them out and still maintain metadata. I could directly connect A_B and MMDVM_Bridge to the XLX reflector and only direct DStar traffic to the module, and audio between DStar and the other digital modes should be about the same as it is now, but audio from Allstar to DStar has one less generation of vocoding, but then I lose metadata between the digital modes. At least, this is how I understand it.


On 11/25/2020 6:55 PM, Steve N4IRS wrote:
Patrick,
Either way, you have to go through a vocoder to go from analog to D-Star Same for P25, you still have to go through a vocoder.

Steve

On 11/25/20 6:28 PM, Patrick Perdue wrote:
Hi:

I have a system that incorporates ASL, XLX, HBLink and DVSwitch. I'm toying with the idea of adding P25.

Currently, DStar is handled by XLX and a pair of transcoders connected to the XLX reflector, not DVSwitch. I would like to connect ASL directly to the XLX reflector in DStar mode, so that the audio to and from DStar to ASL is not transcoded through AMBE, but still pass metadata to DStar from the other digital modes. Is this at all possible? Similar question in regards to P25.

Basically, I want to do the least amount of transcoding possible to and from analog, while maintaining the greatest compatibility across digital modes. What I have now works, but I'd love to get rid of that extra layer of transcoding between analog and DStar without sacrificing metadata.

Thanks.




















Re: metadata management

Patrick Perdue
 

I'm not great at writing out flows.

My setup currently doesn't use ircDDBGateway, since that's all handled at the XLX reflector end. So, it goes like this.

Allstar <-> AB <-> HBLink <-> MB <-> XLXD (DMR, since XLX is also handling a BM interlink and YSF traffic) <-> ambed (connected to the XLX reflector) <-> TGIF.

I'm sure I screwed that up.

So basically, native AMBE traffic is transcoded to analog using the MD380-emu vocoder back to Allstar. DStar is transcoded through the pair of ThumnDV's on the reflector, which is then sent to MD380emu and then Allstar. Between DMR or YSF and DStar, this is fine, but from Allstar to DStar, it's going through another AMBE transcode before A_B sees it, so more latency and lower quality audio.

If I connect to the reflector directly as DStar, then use ASL to connect to the other modes, perhaps on another module of the reflector and HBLink, then DMR-YSF would only see the call specified in A_B, correct?

On 11/25/2020 7:18 PM, Steve N4IRS wrote:
I don't see how there are 2 vocoders to get from AllStar to D-Star. The flow would be:
AllStar <-> AB <-> MB <-> ircDDBGateway <-> XLX for D-Star.
You could drop the ircDDBGateway and go to XLX DMR.

Steve

On 11/25/20 7:14 PM, Patrick Perdue wrote:
Sure, but I'm currently going through two of them to get from Allstar to DStar.

I'm just wondering if there's a way to drop one of them out and still maintain metadata. I could directly connect A_B and MMDVM_Bridge to the XLX reflector and only direct DStar traffic to the module, and audio between DStar and the other digital modes should be about the same as it is now, but audio from Allstar to DStar has one less generation of vocoding, but then I lose metadata between the digital modes. At least, this is how I understand it.


On 11/25/2020 6:55 PM, Steve N4IRS wrote:
Patrick,
Either way, you have to go through a vocoder to go from analog to D-Star Same for P25, you still have to go through a vocoder.

Steve

On 11/25/20 6:28 PM, Patrick Perdue wrote:
Hi:

I have a system that incorporates ASL, XLX, HBLink and DVSwitch. I'm toying with the idea of adding P25.

Currently, DStar is handled by XLX and a pair of transcoders connected to the XLX reflector, not DVSwitch. I would like to connect ASL directly to the XLX reflector in DStar mode, so that the audio to and from DStar to ASL is not transcoded through AMBE, but still pass metadata to DStar from the other digital modes. Is this at all possible? Similar question in regards to P25.

Basically, I want to do the least amount of transcoding possible to and from analog, while maintaining the greatest compatibility across digital modes. What I have now works, but I'd love to get rid of that extra layer of transcoding between analog and DStar without sacrificing metadata.

Thanks.

















Re: metadata management

Steve N4IRS
 

I don't see how there are 2 vocoders to get from AllStar to D-Star. The flow would be:
AllStar <-> AB <-> MB <-> ircDDBGateway <-> XLX for D-Star.
You could drop the ircDDBGateway and go to XLX DMR.

Steve

On 11/25/20 7:14 PM, Patrick Perdue wrote:
Sure, but I'm currently going through two of them to get from Allstar to DStar.

I'm just wondering if there's a way to drop one of them out and still maintain metadata. I could directly connect A_B and MMDVM_Bridge to the XLX reflector and only direct DStar traffic to the module, and audio between DStar and the other digital modes should be about the same as it is now, but audio from Allstar to DStar has one less generation of vocoding, but then I lose metadata between the digital modes. At least, this is how I understand it.


On 11/25/2020 6:55 PM, Steve N4IRS wrote:
Patrick,
Either way, you have to go through a vocoder to go from analog to D-Star Same for P25, you still have to go through a vocoder.

Steve

On 11/25/20 6:28 PM, Patrick Perdue wrote:
Hi:

I have a system that incorporates ASL, XLX, HBLink and DVSwitch. I'm toying with the idea of adding P25.

Currently, DStar is handled by XLX and a pair of transcoders connected to the XLX reflector, not DVSwitch. I would like to connect ASL directly to the XLX reflector in DStar mode, so that the audio to and from DStar to ASL is not transcoded through AMBE, but still pass metadata to DStar from the other digital modes. Is this at all possible? Similar question in regards to P25.

Basically, I want to do the least amount of transcoding possible to and from analog, while maintaining the greatest compatibility across digital modes. What I have now works, but I'd love to get rid of that extra layer of transcoding between analog and DStar without sacrificing metadata.

Thanks.













Re: metadata management

Patrick Perdue
 

Sure, but I'm currently going through two of them to get from Allstar to DStar.

I'm just wondering if there's a way to drop one of them out and still maintain metadata. I could directly connect A_B and MMDVM_Bridge to the XLX reflector and only direct DStar traffic to the module, and audio between DStar and the other digital modes should be about the same as it is now, but audio from Allstar to DStar has one less generation of vocoding, but then I lose metadata between the digital modes. At least, this is how I understand it.

On 11/25/2020 6:55 PM, Steve N4IRS wrote:
Patrick,
Either way, you have to go through a vocoder to go from analog to D-Star Same for P25, you still have to go through a vocoder.

Steve

On 11/25/20 6:28 PM, Patrick Perdue wrote:
Hi:

I have a system that incorporates ASL, XLX, HBLink and DVSwitch. I'm toying with the idea of adding P25.

Currently, DStar is handled by XLX and a pair of transcoders connected to the XLX reflector, not DVSwitch. I would like to connect ASL directly to the XLX reflector in DStar mode, so that the audio to and from DStar to ASL is not transcoded through AMBE, but still pass metadata to DStar from the other digital modes. Is this at all possible? Similar question in regards to P25.

Basically, I want to do the least amount of transcoding possible to and from analog, while maintaining the greatest compatibility across digital modes. What I have now works, but I'd love to get rid of that extra layer of transcoding between analog and DStar without sacrificing metadata.

Thanks.










Re: metadata management

Steve N4IRS
 

Patrick,
Either way, you have to go through a vocoder to go from analog to D-Star Same for P25, you still have to go through a vocoder.

Steve

On 11/25/20 6:28 PM, Patrick Perdue wrote:
Hi:

I have a system that incorporates ASL, XLX, HBLink and DVSwitch. I'm toying with the idea of adding P25.

Currently, DStar is handled by XLX and a pair of transcoders connected to the XLX reflector, not DVSwitch. I would like to connect ASL directly to the XLX reflector in DStar mode, so that the audio to and from DStar to ASL is not transcoded through AMBE, but still pass metadata to DStar from the other digital modes. Is this at all possible? Similar question in regards to P25.

Basically, I want to do the least amount of transcoding possible to and from analog, while maintaining the greatest compatibility across digital modes. What I have now works, but I'd love to get rid of that extra layer of transcoding between analog and DStar without sacrificing metadata.

Thanks.





2381 - 2400 of 9906