Date   

Re: DVSwitch Status update

Paul Nannery KC2VRJ
 

Stave,
Any more information on this MD380emu 

On Mar 21, 2018 9:25 AM, "Steve N4IRS" <szingman@...> wrote:
It has been quite a while since we posted a status update on all of the projects either in the works or deployed. The toolkit is growing and maturing. We are adding connections to more Networks and changing the method we use to connect.

I'll start with DMR. There are multiple DMR networks in use by Amateur Radio. Two of the biggest are HomeBrew based networks (BrandMeister) and IPSC based networks (DMR-MARC). The nice thing about a HB network is that it is open. Cort and Mike have done a lot of work to fix bugs and expand the capability of the HB and IPSC connection tools. Work is being done to enhance the handling of much of the Metadata received from and sent to a HB network. Talker Alias is only one example of the enhancement in the works. Work is being done to find and squash bugs in the IPSC connections. This is harder to do since we have to learn what is going on by reverse engineering.

The connection to D-Star is changing for the better. Again, we have the advantage of open source. The existing connection is built with a modification to DummyRepeater from G4KLX. It made sense at the time since the main purpose of connecting to D-Star was to replace a aging AllStarLink connection method. DummyRepeater gave us most everything we needed to connect and import / export analog audio. DummyRepeater came with a LOT of baggage we did not need and it required some neat tricks to make it work headless. With the next iteration of the D-Star connector, DummyRepeater will no longer be used. This will allow us to standardize the import /export. Metadata is one important part of the upcoming change.

For P25, a number of things are changing and there will be some additions. For P25_Bridge we connect to the MMDVM P25 Network of reflectors. The Network is quite simple and very effective. For each talk group there is a reflector. Each reflector can be on a single host or a host can have more then one reflector. There is at least one other P25 Network in use for Amateur Radio. That Network is P25NX. P25NX is built for Motorola Quantar repeaters. The Quantar (and other Motorola repeaters) is native P25. The P25NX network leverages the ability for a Quantar to be connected to another Quantar either locally or via a modem. P25NX expanded on that feature to allow a network of repeaters. They use a surplus Cisco router and a small host computer (RPi) to build the node. Thanks to the work of NX4Y and others, we decided to leverage the Cisco router to connect to the MMDVM P25 Network. We have built a proof of concept software connector. Quantar_Bridge runs on small host and uses P25Gateway to connect the Quantar to the MMDVM network. The software is still early and we would like to remove the need for the Cisco router. Stay tuned.

Analog_Bridge is continuing to go through changes (can you say feature creep?) Analog_Bridge started life with a different name. It was first called DMRGateway. We decided there were two things wrong with that name. One is it's not a gateway, it's a bridge and more importantly, it does more then DMR. We renamed it Analog_Bridge (days before G4KLX release what he called DMRGateway) Analog_Bridge has the ability to convert analog audio and signaling to digital. For audio, Analog_Bridge uses a Vocoder. That Vocoder can be a hardware Vocoder from a number of vendors including DVMega, Internet Labs and NW Digital Radio. Analog_Bridge will also support software based Vocoders like the MD380emu (on hosts that can run MD380emu) and others. The inclusion of support for other codecs can be added later. The method we used for import / export of analog data was borrowed from the AllStarLink USRP channel driver. Using USRP gave us a way to import / export audio from AllStarLink without any modifications to the channel_driver. USRP also provides signaling (COS, PTT) and a simple form of Metadata. The MetaData component will be expanded as needed. One of the requests we have had is the ability for connection to a network from a PC or SmartPhone / Tablet. USRP works quite well for this. Mike has built USRP client programs for Desktops (Python) and has a working on a iPhone version. The advantage of this approach, is that the client can be quite lightweight. The heavy lifting is done by Analog_Bridge.

A bridge to YSF is being added. YSF_Bridge will use parts from the MMDVM project, so we will have the same capabilities as existing connections. There are quite a few interesting things that will be possible.

A new entry to the family will be NXDN. We plan to add NXDN tools to DVSwitch. We will use the same concepts and methods to leverage the MMDVM project. Stay tuned.

All of the work being done to the bridge tools are intended to standardize the import and export of data. That data can be audio or metadata. Each target network has its own unique set of feature (and challenges) The work is to build a method of interchanging data. Some times that interchange is a one for one relationship. Callsign is a example of that type of relationship. Every network in some way supports the user callsign. On some networks, that callsign has to be derived from other data (DMR, P25...) On D-Star that data is explicit. Other data is unique to a network and may need to be derived. DMR Slot number is a example of this. For HB ---> IPSC this can be (but does not have to be) one to one. For DMR ---> P25, slot has little if any value. For P25 ---> DMR it will have to be derived. For audio the relationship is somewhat simpler. It is either one to one or it's not. A good example of one for one is DMR <---> YSF Narrow. These two modes use the same Vocoder. Some manipulation of the packaging of the data is needed but the AMBE is the same. Again, Metadata will require some manipulation. Digital to analog requires a conversion. This is the job of Analog_Bridge. For example DMR <---> AllStarLink the conversion is AMBE to PCM. When two networks do not share a common Vocoder (or the data is somewhat different) we have to transcode. We transcode by using a Vocoder to convert the data to PCM. That PCM data is exported to another instance of Analog_Bridge where the PCM is imported and converted by a second Vocoder.

Since quite a few of the bridges in uses include AllStarLink I'll update that status too. I have finished up the next release of AllStarLink. We have made quite a few changes to both installation method(s) and usability. With this release, the install is a simple "apt-get install allstarlink" This method uses the standard Debian APT package system. This will allow for much faster turn around of bug fixes and enhancements. As always, the source code is published on GitHub.

Are thing moving slower then we would like? You bet. The work take time and we pay a lot of attention to where we want to go. It does not make sense to code something and just push it out when we know the change will have to be removed down the road to get us where we want to go. This is like chess, we have to look a few moves ahead and pln how we get there. The feedback from the user base is invaluable. No developer in his (her) right mind is going to understand every use case. You have no idea how many e-mails get sent with "I never thought of that!" We are three guys with day jobs, families and lots of projects on our plates. The work is getting done and there is quite a bit of interaction between projects.

For DVSwitch,
73, Steve N4IRS




Re: DVSwitch Status update

 

Thanks for  the update Steve,  Not enough words to express my apprecation to  the work you guys are doing ....

Richard VE2DJE

Le 21/03/2018 à 09:25, Steve N4IRS a écrit :
It has been quite a while since we posted a status update on all of the projects either in the works or deployed. The toolkit is growing and maturing. We are adding connections to more Networks and changing the method we use to connect.

I'll start with DMR. There are multiple DMR networks in use by Amateur Radio. Two of the biggest are HomeBrew based networks (BrandMeister) and IPSC based networks (DMR-MARC). The nice thing about a HB network is that it is open. Cort and Mike have done a lot of work to fix bugs and expand the capability of the HB and IPSC connection tools. Work is being done to enhance the handling of much of the Metadata received from and sent to a HB network. Talker Alias is only one example of the enhancement in the works. Work is being done to find and squash bugs in the IPSC connections. This is harder to do since we have to learn what is going on by reverse engineering.

The connection to D-Star is changing for the better. Again, we have the advantage of open source. The existing connection is built with a modification to DummyRepeater from G4KLX. It made sense at the time since the main purpose of connecting to D-Star was to replace a aging AllStarLink connection method. DummyRepeater gave us most everything we needed to connect and import / export analog audio. DummyRepeater came with a LOT of baggage we did not need and it required some neat tricks to make it work headless. With the next iteration of the D-Star connector, DummyRepeater will no longer be used. This will allow us to standardize the import /export. Metadata is one important part of the upcoming change.

For P25, a number of things are changing and there will be some additions. For P25_Bridge we connect to the MMDVM P25 Network of reflectors. The Network is quite simple and very effective. For each talk group there is a reflector. Each reflector can be on a single host or a host can have more then one reflector. There is at least one other P25 Network in use for Amateur Radio. That Network is P25NX. P25NX is built for Motorola Quantar repeaters. The Quantar (and other Motorola repeaters) is native P25. The P25NX network leverages the ability for a Quantar to be connected to another Quantar either locally or via a modem. P25NX expanded on that feature to allow a network of repeaters. They use a surplus Cisco router and a small host computer (RPi) to build the node. Thanks to the work of NX4Y and others, we decided to leverage the Cisco router to connect to the MMDVM P25 Network. We have built a proof of concept software connector. Quantar_Bridge runs on small host and uses P25Gateway to connect the Quantar to the MMDVM network. The software is still early and we would like to remove the need for the Cisco router. Stay tuned.

Analog_Bridge is continuing to go through changes (can you say feature creep?) Analog_Bridge started life with a different name. It was first called DMRGateway. We decided there were two things wrong with that name. One is it's not a gateway, it's a bridge and more importantly, it does more then DMR. We renamed it Analog_Bridge (days before G4KLX release what he called DMRGateway) Analog_Bridge has the ability to convert analog audio and signaling to digital. For audio, Analog_Bridge uses a Vocoder. That Vocoder can be a hardware Vocoder from a number of vendors including DVMega, Internet Labs and NW Digital Radio. Analog_Bridge will also support software based Vocoders like the MD380emu (on hosts that can run MD380emu) and others. The inclusion of support for other codecs can be added later. The method we used for import / export of analog data was borrowed from the AllStarLink USRP channel driver. Using USRP gave us a way to import / export audio from AllStarLink without any modifications to the channel_driver. USRP also provides signaling (COS, PTT) and a simple form of Metadata. The MetaData component will be expanded as needed. One of the requests we have had is the ability for connection to a network from a PC or SmartPhone / Tablet. USRP works quite well for this. Mike has built USRP client programs for Desktops (Python) and has a working on a iPhone version. The advantage of this approach, is that the client can be quite lightweight. The heavy lifting is done by Analog_Bridge.

A bridge to YSF is being added. YSF_Bridge will use parts from the MMDVM project, so we will have the same capabilities as existing connections. There are quite a few interesting things that will be possible.

A new entry to the family will be NXDN. We plan to add NXDN tools to DVSwitch. We will use the same concepts and methods to leverage the MMDVM project. Stay tuned.

All of the work being done to the bridge tools are intended to standardize the import and export of data. That data can be audio or metadata. Each target network has its own unique set of feature (and challenges) The work is to build a method of interchanging data. Some times that interchange is a one for one relationship. Callsign is a example of that type of relationship. Every network in some way supports the user callsign. On some networks, that callsign has to be derived from other data (DMR, P25...) On D-Star that data is explicit. Other data is unique to a network and may need to be derived. DMR Slot number is a example of this. For HB ---> IPSC this can be (but does not have to be) one to one. For DMR ---> P25, slot has little if any value. For P25 ---> DMR it will have to be derived. For audio the relationship is somewhat simpler. It is either one to one or it's not. A good example of one for one is DMR <---> YSF Narrow. These two modes use the same Vocoder. Some manipulation of the packaging of the data is needed but the AMBE is the same. Again, Metadata will require some manipulation. Digital to analog requires a conversion. This is the job of Analog_Bridge. For example DMR <---> AllStarLink the conversion is AMBE to PCM. When two networks do not share a common Vocoder (or the data is somewhat different) we have to transcode. We transcode by using a Vocoder to convert the data to PCM. That PCM data is exported to another instance of Analog_Bridge where the PCM is imported and converted by a second Vocoder.

Since quite a few of the bridges in uses include AllStarLink I'll update that status too. I have finished up the next release of AllStarLink. We have made quite a few changes to both installation method(s) and usability. With this release, the install is a simple "apt-get install allstarlink" This method uses the standard Debian APT package system. This will allow for much faster turn around of bug fixes and enhancements. As always, the source code is published on GitHub.

Are thing moving slower then we would like? You bet. The work take time and we pay a lot of attention to where we want to go. It does not make sense to code something and just push it out when we know the change will have to be removed down the road to get us where we want to go. This is like chess, we have to look a few moves ahead and pln how we get there. The feedback from the user base is invaluable. No developer in his (her) right mind is going to understand every use case. You have no idea how many e-mails get sent with "I never thought of that!" We are three guys with day jobs, families and lots of projects on our plates. The work is getting done and there is quite a bit of interaction between projects.

For DVSwitch,
73, Steve N4IRS



---
This email has been checked for viruses by AVG.
http://www.avg.com


DVSwitch Status update

Steve N4IRS
 

It has been quite a while since we posted a status update on all of the projects either in the works or deployed. The toolkit is growing and maturing. We are adding connections to more Networks and changing the method we use to connect.

I'll start with DMR. There are multiple DMR networks in use by Amateur Radio. Two of the biggest are HomeBrew based networks (BrandMeister) and IPSC based networks (DMR-MARC). The nice thing about a HB network is that it is open. Cort and Mike have done a lot of work to fix bugs and expand the capability of the HB and IPSC connection tools. Work is being done to enhance the handling of much of the Metadata received from and sent to a HB network. Talker Alias is only one example of the enhancement in the works. Work is being done to find and squash bugs in the IPSC connections. This is harder to do since we have to learn what is going on by reverse engineering.

The connection to D-Star is changing for the better. Again, we have the advantage of open source. The existing connection is built with a modification to DummyRepeater from G4KLX. It made sense at the time since the main purpose of connecting to D-Star was to replace a aging AllStarLink connection method. DummyRepeater gave us most everything we needed to connect and import / export analog audio. DummyRepeater came with a LOT of baggage we did not need and it required some neat tricks to make it work headless. With the next iteration of the D-Star connector, DummyRepeater will no longer be used. This will allow us to standardize the import /export. Metadata is one important part of the upcoming change.

For P25, a number of things are changing and there will be some additions. For P25_Bridge we connect to the MMDVM P25 Network of reflectors. The Network is quite simple and very effective. For each talk group there is a reflector. Each reflector can be on a single host or a host can have more then one reflector. There is at least one other P25 Network in use for Amateur Radio. That Network is P25NX. P25NX is built for Motorola Quantar repeaters. The Quantar (and other Motorola repeaters) is native P25. The P25NX network leverages the ability for a Quantar to be connected to another Quantar either locally or via a modem. P25NX expanded on that feature to allow a network of repeaters. They use a surplus Cisco router and a small host computer (RPi) to build the node. Thanks to the work of NX4Y and others, we decided to leverage the Cisco router to connect to the MMDVM P25 Network. We have built a proof of concept software connector. Quantar_Bridge runs on small host and uses P25Gateway to connect the Quantar to the MMDVM network. The software is still early and we would like to remove the need for the Cisco router. Stay tuned.

Analog_Bridge is continuing to go through changes (can you say feature creep?) Analog_Bridge started life with a different name. It was first called DMRGateway. We decided there were two things wrong with that name. One is it's not a gateway, it's a bridge and more importantly, it does more then DMR. We renamed it Analog_Bridge (days before G4KLX release what he called DMRGateway) Analog_Bridge has the ability to convert analog audio and signaling to digital. For audio, Analog_Bridge uses a Vocoder. That Vocoder can be a hardware Vocoder from a number of vendors including DVMega, Internet Labs and NW Digital Radio. Analog_Bridge will also support software based Vocoders like the MD380emu (on hosts that can run MD380emu) and others. The inclusion of support for other codecs can be added later. The method we used for import / export of analog data was borrowed from the AllStarLink USRP channel driver. Using USRP gave us a way to import / export audio from AllStarLink without any modifications to the channel_driver. USRP also provides signaling (COS, PTT) and a simple form of Metadata. The MetaData component will be expanded as needed. One of the requests we have had is the ability for connection to a network from a PC or SmartPhone / Tablet. USRP works quite well for this. Mike has built USRP client programs for Desktops (Python) and has a working on a iPhone version. The advantage of this approach, is that the client can be quite lightweight. The heavy lifting is done by Analog_Bridge.

A bridge to YSF is being added. YSF_Bridge will use parts from the MMDVM project, so we will have the same capabilities as existing connections. There are quite a few interesting things that will be possible.

A new entry to the family will be NXDN. We plan to add NXDN tools to DVSwitch. We will use the same concepts and methods to leverage the MMDVM project. Stay tuned.

All of the work being done to the bridge tools are intended to standardize the import and export of data. That data can be audio or metadata. Each target network has its own unique set of feature (and challenges) The work is to build a method of interchanging data. Some times that interchange is a one for one relationship. Callsign is a example of that type of relationship. Every network in some way supports the user callsign. On some networks, that callsign has to be derived from other data (DMR, P25...) On D-Star that data is explicit. Other data is unique to a network and may need to be derived. DMR Slot number is a example of this. For HB ---> IPSC this can be (but does not have to be) one to one. For DMR ---> P25, slot has little if any value. For P25 ---> DMR it will have to be derived. For audio the relationship is somewhat simpler. It is either one to one or it's not. A good example of one for one is DMR <---> YSF Narrow. These two modes use the same Vocoder. Some manipulation of the packaging of the data is needed but the AMBE is the same. Again, Metadata will require some manipulation. Digital to analog requires a conversion. This is the job of Analog_Bridge. For example DMR <---> AllStarLink the conversion is AMBE to PCM. When two networks do not share a common Vocoder (or the data is somewhat different) we have to transcode. We transcode by using a Vocoder to convert the data to PCM. That PCM data is exported to another instance of Analog_Bridge where the PCM is imported and converted by a second Vocoder.

Since quite a few of the bridges in uses include AllStarLink I'll update that status too. I have finished up the next release of AllStarLink. We have made quite a few changes to both installation method(s) and usability. With this release, the install is a simple "apt-get install allstarlink" This method uses the standard Debian APT package system. This will allow for much faster turn around of bug fixes and enhancements. As always, the source code is published on GitHub.

Are thing moving slower then we would like? You bet. The work take time and we pay a lot of attention to where we want to go. It does not make sense to code something and just push it out when we know the change will have to be removed down the road to get us where we want to go. This is like chess, we have to look a few moves ahead and pln how we get there. The feedback from the user base is invaluable. No developer in his (her) right mind is going to understand every use case. You have no idea how many e-mails get sent with "I never thought of that!" We are three guys with day jobs, families and lots of projects on our plates. The work is getting done and there is quite a bit of interaction between projects.

For DVSwitch,
73, Steve N4IRS


Re: P25 Integration via AllStar Link

Steve N4IRS
 

You will not need a DIU at all. The analog to P25 conversion will be done with a piece of software called P25_Bridge on the right side of the diagram. The Cisco is a 1841 router just like P25NX uses. We hope to replace it with a custom board that handles the HDLC data, but for now it works with the Cisco. We are very early in the Quantar to MMDVM connection and have at least one major bug to squash. The bug is in the Metadata from the MMDVM Nettwork to the Quantar.

Steve

On 3/20/2018 1:14 PM, William Freeman wrote:
Steve

It sounds about right.

I’m basically trying to maintain a P25 network of repeaters that are linked to a few FM repeaters and simplex nodes. Mostly just to say that I can do it (I like tinkering with radio stuff).

Would I need to purchase a DIU for each repeater or just the cisco board that you mentioned?


William Freeman

On Mar 20, 2018, at 10:08 AM, Steve N4IRS <szingman@...> wrote:

Bill,
If I understand, you would like to connect a P25 Quantar in P25 mode to a AllStarLink network. That is quite possible though it takes a few things. We can connect a AllStarLink network to the MMDVM P25 Reflector system. We can also connect a Quantar to the MMDVM P25 Reflector system. As of today, the code is early but all the pieces work. For the Quantar, TODAY we still require the same V.24 board and Cisco router that P25NX uses. To be clear, no The P25NX network is not involved. We just use the same hardware. The MMDVM P25 Reflector is open source, so that is not a problem. It would look something like this:

Quantar <---> Cisco <---> RPi <---> MMDVM Reflector <---> RPi <---> AllStarLink

This is a very simplistic layout. On the Quantar side, multiple repeaters could connect to the reflector. On the AllStarLink side, the node could be connected to a AllStarLink HUB.
The computers in the diagram are RaspberryPi. The can be any type of Linux machine you like. The MMDVM Reflector and the AllStarLink node could be on a single computer. This starts depending on how you want to build it.

Could we drop the MMDVM Reflector? Yes. Each Quantar could have all the hardware and software to connect to the AllStarLink network.

As I said the code is early. We are working to release the software parts to make this happen. I do not have a time frame at this time.If this is something you would like to move forward with, we can go deeper.

Some of this depends on how you want to lay it out.

73, Steve N4IRS


Re: P25 Integration via AllStar Link

William Freeman
 

Steve

It sounds about right.

I’m basically trying to maintain a P25 network of repeaters that are linked to a few FM repeaters and simplex nodes. Mostly just to say that I can do it (I like tinkering with radio stuff).

Would I need to purchase a DIU for each repeater or just the cisco board that you mentioned?


William Freeman

On Mar 20, 2018, at 10:08 AM, Steve N4IRS <szingman@...> wrote:

Bill,
If I understand, you would like to connect a P25 Quantar in P25 mode to a AllStarLink network. That is quite possible though it takes a few things. We can connect a AllStarLink network to the MMDVM P25 Reflector system. We can also connect a Quantar to the MMDVM P25 Reflector system. As of today, the code is early but all the pieces work. For the Quantar, TODAY we still require the same V.24 board and Cisco router that P25NX uses. To be clear, no The P25NX network is not involved. We just use the same hardware. The MMDVM P25 Reflector is open source, so that is not a problem. It would look something like this:

Quantar <---> Cisco <---> RPi <---> MMDVM Reflector <---> RPi <---> AllStarLink

This is a very simplistic layout. On the Quantar side, multiple repeaters could connect to the reflector. On the AllStarLink side, the node could be connected to a AllStarLink HUB.
The computers in the diagram are RaspberryPi. The can be any type of Linux machine you like. The MMDVM Reflector and the AllStarLink node could be on a single computer. This starts depending on how you want to build it.

Could we drop the MMDVM Reflector? Yes. Each Quantar could have all the hardware and software to connect to the AllStarLink network.

As I said the code is early. We are working to release the software parts to make this happen. I do not have a time frame at this time.If this is something you would like to move forward with, we can go deeper.

Some of this depends on how you want to lay it out.

73, Steve N4IRS


Re: P25 Integration via AllStar Link

Steve N4IRS
 

Bill,
If I understand, you would like to connect a P25 Quantar in P25 mode to a AllStarLink network. That is quite possible though it takes a few things. We can connect a AllStarLink network to the MMDVM P25 Reflector system. We can also connect a Quantar to the MMDVM P25 Reflector system. As of today, the code is early but all the pieces work. For the Quantar, TODAY we still require the same V.24 board and Cisco router that P25NX uses. To be clear, no The P25NX network is not involved. We just use the same hardware. The MMDVM P25 Reflector is open source, so that is not a problem. It would look something like this:

Quantar <---> Cisco <---> RPi <---> MMDVM Reflector <---> RPi <---> AllStarLink

This is a very simplistic layout. On the Quantar side, multiple repeaters could connect to the reflector. On the AllStarLink side, the node could be connected to a AllStarLink HUB.
The computers in the diagram are RaspberryPi. The can be any type of Linux machine you like. The MMDVM Reflector and the AllStarLink node could be on a single computer. This starts depending on how you want to build it.

Could we drop the MMDVM Reflector? Yes. Each Quantar could have all the hardware and software to connect to the AllStarLink network.

As I said the code is early. We are working to release the software parts to make this happen. I do not have a time frame at this time.If this is something you would like to move forward with, we can go deeper.

Some of this depends on how you want to lay it out.

73, Steve N4IRS


P25 Integration via AllStar Link

William Freeman
 

Good morning, everyone!

I was pointed over here from the AllStar Link mailing list. I own and operate several mixed-mode P25/FM ham machines (100w Quantars) in Las Vegas. Currently, the FM machine is connected to the AllStar Link system while the P25 is standalone. I would like to ultimately run P25 exclusively but still have it connected to the local AllStar network here in Vegas that has FM-only machines. Has anyone accomplished this? Does anyone have the procedures for doing this? I am not interested in connecting the P25nx system, but rather the overall AllStar Link system.

Bill N4NJJ

--
William Freeman


Re: ASL>DStar noise problem

G7RPG - Peter Kendall
 

Thanks Steve K4SQ,

That fixed it, changed to 1.5 and DStar audio levels now much closer to others on Allstar.

73
Peter
G7RPG


On 19/03/18 16:37, Steven Blackford wrote:

Peter/Steve,

    I ran into this problem a while back.  Peter, you have to modify the DummyRepeaterThread.cpp file.  The division by 3 drops the audio level pretty low.  So, I modified it to multiple by 1.5 instead.  If increase it to 2.0 or higher, you’ll start getting bad clipping, so I just left it @ 1.5.  It was late in the middle of the night when I looked @ this & it’s probably not the right way to correct the problem, but it has been working here. 😉 Here’s the change I made:

 

[root@k4sqi-allstar DummyRepeater]# diff DummyRepeaterThread.cpp.USRP.orig DummyRepeaterThread.cpp

80c80

<                       m_usrpPacket.audio[i] = (short)((audio[i*6]) * 32768.0F /  3.0F);

---

>                       m_usrpPacket.audio[i] = (short)((audio[i*6]) * 32768.0F *  1.5F);

[root@k4sqi-allstar DummyRepeater]#

 

73 de K4SQI!

 

Steve, K4SQI

 

From: G7RPG - Peter Kendall
Sent: Monday, March 19, 2018 12:26 PM
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] ASL>DStar noise problem

 

Steve,

Do you know if it is possible to manipulate the audio levels like you can with analog_bridge, DSTAR>ASL is quite low.

73
Peter

 

On 15/03/18 13:12, G7RPG - Peter Kendall wrote:

BINGO!

That fixed it, thanks Steve.

Its running under ESX and added an 'HD audio' device.

73
Peter

 

On 15/03/18 12:56, Steve N4IRS wrote:

OK, I may have to go back and find that message and edit it. DO you have a real sound device available in those pulldowns? If so select it. If not, can you add a simple sound device like a CM1xx and select it?

Steve

On 3/15/2018 8:53 AM, G7RPG - Peter Kendall wrote:

Hi Steve,

Yes, followed your instructions from a previous post.

Peter

 

On 15/03/18 12:47, Steve N4IRS wrote:

Peter,
I'm pulling this off the top of my head. Do you have the sound device in Dummy Repeater using snd-dummy?

73, Steve

On 3/15/2018 7:59 AM, G7RPG - Peter Kendall wrote:

Hi All,

I've got my Allstar node connected to DStar (DCS005E) using the dvswitch
modified version of dummy repeater.

All seems to be working well apart from a digital burst of noise that is
heard on DStar at the end of a transmission coming from ASL.

I've recorded an example here: https://www.youtube.com/watch?v=APkGjoLxKPk

I wonder if anyone has any suggestions or has come across this before?

73
Peter
G7RPG







 

 

 

 

 



Re: ASL>DStar noise problem

Steven Blackford
 

Peter/Steve,

    I ran into this problem a while back.  Peter, you have to modify the DummyRepeaterThread.cpp file.  The division by 3 drops the audio level pretty low.  So, I modified it to multiple by 1.5 instead.  If increase it to 2.0 or higher, you’ll start getting bad clipping, so I just left it @ 1.5.  It was late in the middle of the night when I looked @ this & it’s probably not the right way to correct the problem, but it has been working here. 😉 Here’s the change I made:

 

[root@k4sqi-allstar DummyRepeater]# diff DummyRepeaterThread.cpp.USRP.orig DummyRepeaterThread.cpp

80c80

<                       m_usrpPacket.audio[i] = (short)((audio[i*6]) * 32768.0F /  3.0F);

---

>                       m_usrpPacket.audio[i] = (short)((audio[i*6]) * 32768.0F *  1.5F);

[root@k4sqi-allstar DummyRepeater]#

 

73 de K4SQI!

 

Steve, K4SQI

 

From: G7RPG - Peter Kendall
Sent: Monday, March 19, 2018 12:26 PM
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] ASL>DStar noise problem

 

Steve,

Do you know if it is possible to manipulate the audio levels like you can with analog_bridge, DSTAR>ASL is quite low.

73
Peter

 

On 15/03/18 13:12, G7RPG - Peter Kendall wrote:

BINGO!

That fixed it, thanks Steve.

Its running under ESX and added an 'HD audio' device.

73
Peter

 

On 15/03/18 12:56, Steve N4IRS wrote:

OK, I may have to go back and find that message and edit it. DO you have a real sound device available in those pulldowns? If so select it. If not, can you add a simple sound device like a CM1xx and select it?

Steve

On 3/15/2018 8:53 AM, G7RPG - Peter Kendall wrote:

Hi Steve,

Yes, followed your instructions from a previous post.

Peter

 

On 15/03/18 12:47, Steve N4IRS wrote:

Peter,
I'm pulling this off the top of my head. Do you have the sound device in Dummy Repeater using snd-dummy?

73, Steve

On 3/15/2018 7:59 AM, G7RPG - Peter Kendall wrote:

Hi All,

I've got my Allstar node connected to DStar (DCS005E) using the dvswitch
modified version of dummy repeater.

All seems to be working well apart from a digital burst of noise that is
heard on DStar at the end of a transmission coming from ASL.

I've recorded an example here: https://www.youtube.com/watch?v=APkGjoLxKPk

I wonder if anyone has any suggestions or has come across this before?

73
Peter
G7RPG







 

 

 

 

 


Re: ASL>DStar noise problem

G7RPG - Peter Kendall
 

Steve,

Do you know if it is possible to manipulate the audio levels like you can with analog_bridge, DSTAR>ASL is quite low.

73
Peter


On 15/03/18 13:12, G7RPG - Peter Kendall wrote:

BINGO!

That fixed it, thanks Steve.

Its running under ESX and added an 'HD audio' device.

73
Peter


On 15/03/18 12:56, Steve N4IRS wrote:
OK, I may have to go back and find that message and edit it. DO you have a real sound device available in those pulldowns? If so select it. If not, can you add a simple sound device like a CM1xx and select it?

Steve

On 3/15/2018 8:53 AM, G7RPG - Peter Kendall wrote:

Hi Steve,

Yes, followed your instructions from a previous post.

Peter


On 15/03/18 12:47, Steve N4IRS wrote:
Peter,
I'm pulling this off the top of my head. Do you have the sound device in Dummy Repeater using snd-dummy?

73, Steve

On 3/15/2018 7:59 AM, G7RPG - Peter Kendall wrote:
Hi All,

I've got my Allstar node connected to DStar (DCS005E) using the dvswitch
modified version of dummy repeater.

All seems to be working well apart from a digital burst of noise that is
heard on DStar at the end of a transmission coming from ASL.

I've recorded an example here: https://www.youtube.com/watch?v=APkGjoLxKPk

I wonder if anyone has any suggestions or has come across this before?

73
Peter
G7RPG














Re: HBLink Parrot Settings

DO1KBL, Kim
 

Okay,
I will try it today in give u a feedback its working or not :-)


Re: HBLink Parrot Settings

Cort N0MJS <n0mjs@...>
 

You’re running two copies of hblink.py:

hb_confbridge.py will call hblink.py underneath it (as a module)
hb_parrot.py will call hblink.py underneath it (as a module)

These are the two programs you should be starting. Nothing else, just hb_confbridge.py and hb_parrot.py

Both of those, as I pointed out in the beginning will instantiate their own copies of hblink.py. You’ll either need duplicate copies of the hblink directory for this, or make sure and call one copy with an alternate configuration file – which id looks like you’re doing with hblink_parrot.cfg – so I assume that hblink.cfg (default name) is what you’re letting hb_confbridge.py get called with.

So, on two the config files. When I read your hblink.cfg file I find:

3 separate HB systems are created:

Global-Master, which is a “master”, listening on all IP interfaces, UDP port 54000
Global-Client, which is a “client” (mimics a repeater), using the loopback interface, UDP port 54021, connecting to a master on same machine, loopback interface, master is on port 54000
Parrot-Client, which is a “client” (mimics a repeater), using the loopback interface, UDP port 54018, connecting to a master on same machine, loopback interface, master is on port 54004

Let’s move on to hblink_parrot.cfg:

I see one HB system created:

Papagei-Master, which is a “master”, listening on all IP interfaces, UDP Port 54004


And I see hb_confbridge_rules.py that connect both clients to each other:

BRIDGES = {
    'hblink': [
            {'SYSTEM': 'Global-Client', 'TS': 2, 'TGID': 9990, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
            {'SYSTEM': 'Parrot-Client', 'TS': 2, 'TGID': 9990, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
        ]
}


*********************************************

First off, Global Client is completely unnecessary

You only need [Global-Master] and [Parrot-Client] for hb_confbridge.py

Then connect them together with hb_confbridge_py as such:

BRIDGES = {
    'hblink': [
            {'SYSTEM': ‘Global-Master', 'TS': 2, 'TGID': 9990, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
            {'SYSTEM': 'Parrot-Client', 'TS': 2, 'TGID': 9990, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
        ]
}

I do not know why you’re getting port already in use – clearly someone else is already binding to a port used. I’d check your system to see what process has bound itself to that port.


















On Mar 18, 2018, at 12:56 PM, kbluetkemeier via Groups.Io <kbluetkemeier@...> wrote:

[Edited Message Follows]

Today I try it, but its killed :-(


root@Pi:~/HBlink# ./hb_confbridge.py
DEBUG 2018-03-18 18:58:50,896 Logging system started, anything from here on gets logged
INFO 2018-03-18 18:58:50,897 ID ALIAS MAPPER: 'peer_ids.csv' is current, not downloaded
INFO 2018-03-18 18:58:50,898 ID ALIAS MAPPER: 'subscriber_ids.csv' is current, not downloaded
INFO 2018-03-18 18:58:50,899 ID ALIAS MAPPER: peer_ids dictionary is available
INFO 2018-03-18 18:58:51,781 ID ALIAS MAPPER: subscriber_ids dictionary is available
INFO 2018-03-18 18:58:51,784 ID ALIAS MAPPER: talkgroup_ids dictionary is available
INFO 2018-03-18 18:58:51,786 Routing bridges file found and bridges imported
INFO 2018-03-18 18:58:51,787 ACL file found, importing entries. This will take about 1.5 seconds per 1 million IDs
Killed


maybe you can write step by step ?
How i activate the Parrot in the cofig? I find only the way to start the hb_parrot.py but when I defined two Master on the hblink.cfg and I start the confbridge.py or hblink.py he say the ports a used (its correct!)

thank you
Do1KBL, Kim

--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206






Re: HBLink Parrot Settings

Steve N4IRS
 

Polly want a echo?

On 03/18/2018 03:49 PM, Cort N0MJS wrote:
Yep, I absolutely hat the name. Doesn’t matter. Everyone is going to call it parrot. I’ve had to accept I cannot stop that.

On Mar 18, 2018, at 1:41 PM, Peter M0NWI <peter-martin@outlook.com> wrote:

Cort, I remember you telling me off for calling the echo function the parrot :)

________________________________________
From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS <n0mjs@me.com>
Sent: 18 March 2018 18:30:38
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] HBLink Parrot Settings

Maybe you could send your configuration files and I could check them.


On Mar 18, 2018, at 12:56 PM, kbluetkemeier via Groups.Io <kbluetkemeier=yahoo.de@groups.io<mailto:kbluetkemeier=yahoo.de@groups.io>> wrote:


[Edited Message Follows]

Today I try it, but its killed :-(


root@Pi:~/HBlink# ./hb_confbridge.py
DEBUG 2018-03-18 18:58:50,896 Logging system started, anything from here on gets logged
INFO 2018-03-18 18:58:50,897 ID ALIAS MAPPER: 'peer_ids.csv' is current, not downloaded
INFO 2018-03-18 18:58:50,898 ID ALIAS MAPPER: 'subscriber_ids.csv' is current, not downloaded
INFO 2018-03-18 18:58:50,899 ID ALIAS MAPPER: peer_ids dictionary is available
INFO 2018-03-18 18:58:51,781 ID ALIAS MAPPER: subscriber_ids dictionary is available
INFO 2018-03-18 18:58:51,784 ID ALIAS MAPPER: talkgroup_ids dictionary is available
INFO 2018-03-18 18:58:51,786 Routing bridges file found and bridges imported
INFO 2018-03-18 18:58:51,787 ACL file found, importing entries. This will take about 1.5 seconds per 1 million IDs
Killed


maybe you can write step by step ?
How i activate the Parrot in the cofig? I find only the way to start the hb_parrot.py but when I defined two Master on the hblink.cfg and I start the confbridge.py or hblink.py he say the ports a used (its correct!)

thank you
Do1KBL, Kim



--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206







Re: HBLink Parrot Settings

Cort N0MJS <n0mjs@...>
 

Yep, I absolutely hat the name. Doesn’t matter. Everyone is going to call it parrot. I’ve had to accept I cannot stop that.

On Mar 18, 2018, at 1:41 PM, Peter M0NWI <peter-martin@outlook.com> wrote:

Cort, I remember you telling me off for calling the echo function the parrot :)

________________________________________
From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS <n0mjs@me.com>
Sent: 18 March 2018 18:30:38
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] HBLink Parrot Settings

Maybe you could send your configuration files and I could check them.


On Mar 18, 2018, at 12:56 PM, kbluetkemeier via Groups.Io <kbluetkemeier=yahoo.de@groups.io<mailto:kbluetkemeier=yahoo.de@groups.io>> wrote:


[Edited Message Follows]

Today I try it, but its killed :-(


root@Pi:~/HBlink# ./hb_confbridge.py
DEBUG 2018-03-18 18:58:50,896 Logging system started, anything from here on gets logged
INFO 2018-03-18 18:58:50,897 ID ALIAS MAPPER: 'peer_ids.csv' is current, not downloaded
INFO 2018-03-18 18:58:50,898 ID ALIAS MAPPER: 'subscriber_ids.csv' is current, not downloaded
INFO 2018-03-18 18:58:50,899 ID ALIAS MAPPER: peer_ids dictionary is available
INFO 2018-03-18 18:58:51,781 ID ALIAS MAPPER: subscriber_ids dictionary is available
INFO 2018-03-18 18:58:51,784 ID ALIAS MAPPER: talkgroup_ids dictionary is available
INFO 2018-03-18 18:58:51,786 Routing bridges file found and bridges imported
INFO 2018-03-18 18:58:51,787 ACL file found, importing entries. This will take about 1.5 seconds per 1 million IDs
Killed


maybe you can write step by step ?
How i activate the Parrot in the cofig? I find only the way to start the hb_parrot.py but when I defined two Master on the hblink.cfg and I start the confbridge.py or hblink.py he say the ports a used (its correct!)

thank you
Do1KBL, Kim



--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206


Re: HBLink Parrot Settings

Peter M0NWI
 

Cort, I remember you telling me off for calling the echo function the parrot :)

________________________________________
From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS <n0mjs@me.com>
Sent: 18 March 2018 18:30:38
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] HBLink Parrot Settings

Maybe you could send your configuration files and I could check them.


On Mar 18, 2018, at 12:56 PM, kbluetkemeier via Groups.Io <kbluetkemeier=yahoo.de@groups.io<mailto:kbluetkemeier=yahoo.de@groups.io>> wrote:


[Edited Message Follows]

Today I try it, but its killed :-(


root@Pi:~/HBlink# ./hb_confbridge.py
DEBUG 2018-03-18 18:58:50,896 Logging system started, anything from here on gets logged
INFO 2018-03-18 18:58:50,897 ID ALIAS MAPPER: 'peer_ids.csv' is current, not downloaded
INFO 2018-03-18 18:58:50,898 ID ALIAS MAPPER: 'subscriber_ids.csv' is current, not downloaded
INFO 2018-03-18 18:58:50,899 ID ALIAS MAPPER: peer_ids dictionary is available
INFO 2018-03-18 18:58:51,781 ID ALIAS MAPPER: subscriber_ids dictionary is available
INFO 2018-03-18 18:58:51,784 ID ALIAS MAPPER: talkgroup_ids dictionary is available
INFO 2018-03-18 18:58:51,786 Routing bridges file found and bridges imported
INFO 2018-03-18 18:58:51,787 ACL file found, importing entries. This will take about 1.5 seconds per 1 million IDs
Killed


maybe you can write step by step ?
How i activate the Parrot in the cofig? I find only the way to start the hb_parrot.py but when I defined two Master on the hblink.cfg and I start the confbridge.py or hblink.py he say the ports a used (its correct!)

thank you
Do1KBL, Kim


Re: HBLink Parrot Settings

Cort N0MJS <n0mjs@...>
 

Maybe you could send your configuration files and I could check them.


On Mar 18, 2018, at 12:56 PM, kbluetkemeier via Groups.Io <kbluetkemeier@...> wrote:

[Edited Message Follows]

Today I try it, but its killed :-(


root@Pi:~/HBlink# ./hb_confbridge.py
DEBUG 2018-03-18 18:58:50,896 Logging system started, anything from here on gets logged
INFO 2018-03-18 18:58:50,897 ID ALIAS MAPPER: 'peer_ids.csv' is current, not downloaded
INFO 2018-03-18 18:58:50,898 ID ALIAS MAPPER: 'subscriber_ids.csv' is current, not downloaded
INFO 2018-03-18 18:58:50,899 ID ALIAS MAPPER: peer_ids dictionary is available
INFO 2018-03-18 18:58:51,781 ID ALIAS MAPPER: subscriber_ids dictionary is available
INFO 2018-03-18 18:58:51,784 ID ALIAS MAPPER: talkgroup_ids dictionary is available
INFO 2018-03-18 18:58:51,786 Routing bridges file found and bridges imported
INFO 2018-03-18 18:58:51,787 ACL file found, importing entries. This will take about 1.5 seconds per 1 million IDs
Killed


maybe you can write step by step ?
How i activate the Parrot in the cofig? I find only the way to start the hb_parrot.py but when I defined two Master on the hblink.cfg and I start the confbridge.py or hblink.py he say the ports a used (its correct!)

thank you
Do1KBL, Kim


Re: HBLink Parrot Settings

DO1KBL, Kim
 
Edited

Today I try it, but its killed :-(


root@Pi:~/HBlink# ./hb_confbridge.py
DEBUG 2018-03-18 18:58:50,896 Logging system started, anything from here on gets logged
INFO 2018-03-18 18:58:50,897 ID ALIAS MAPPER: 'peer_ids.csv' is current, not downloaded
INFO 2018-03-18 18:58:50,898 ID ALIAS MAPPER: 'subscriber_ids.csv' is current, not downloaded
INFO 2018-03-18 18:58:50,899 ID ALIAS MAPPER: peer_ids dictionary is available
INFO 2018-03-18 18:58:51,781 ID ALIAS MAPPER: subscriber_ids dictionary is available
INFO 2018-03-18 18:58:51,784 ID ALIAS MAPPER: talkgroup_ids dictionary is available
INFO 2018-03-18 18:58:51,786 Routing bridges file found and bridges imported
INFO 2018-03-18 18:58:51,787 ACL file found, importing entries. This will take about 1.5 seconds per 1 million IDs
Killed


maybe you can write step by step ?
How i activate the Parrot in the cofig? I find only the way to start the hb_parrot.py but when I defined two Master on the hblink.cfg and I start the confbridge.py or hblink.py he say the ports a used (its correct!)

thank you
Do1KBL, Kim


Re: HBLink Parrot Settings

Cort N0MJS <n0mjs@...>
 

I think you bay be confused about how the pieces work.

If you’re running confbridge.py and hb_parrot.py, there is no need to run hblink.py on it’s own. 

On Mar 17, 2018, at 1:45 PM, kbluetkemeier via Groups.Io <kbluetkemeier@...> wrote:

I test today but I have no funktion

I Create one Master (Globale Master) here are connecting the MMDVM Hotspots Port 54000 (Start hblink.py)
Than I Create a snd Master (Parrot Master) with the port 54004 (start: hb_parrot.py)

On the first globale Master hblink.cfg I have two client

client-1 connect to the Gloable Master
client-2 connect to the Parrot Master

on the hb_confbridge_rules i write:

BRIDGES = {
    'HBlink': [
            {'SYSTEM': 'client-1',       'TS': 2, 'TGID': 9990, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
            {'SYSTEM': 'client-2',       'TS': 2, 'TGID': 9990, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
        ]
}

I start the hb_confbridge.py he write me over one million he need 1.5 seconds an thats all.

But no communication between Globale Master and Parrot Master :-(



--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206






Re: HBLink Parrot Settings

DO1KBL, Kim
 

I test today but I have no funktion

I Create one Master (Globale Master) here are connecting the MMDVM Hotspots Port 54000 (Start hblink.py)
Than I Create a snd Master (Parrot Master) with the port 54004 (start: hb_parrot.py)

On the first globale Master hblink.cfg I have two client

client-1 connect to the Gloable Master
client-2 connect to the Parrot Master

on the hb_confbridge_rules i write:

BRIDGES = {
    'HBlink': [
            {'SYSTEM': 'client-1',       'TS': 2, 'TGID': 9990, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
            {'SYSTEM': 'client-2',       'TS': 2, 'TGID': 9990, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
        ]
}

I start the hb_confbridge.py he write me over one million he need 1.5 seconds an thats all.

But no communication between Globale Master and Parrot Master :-(



HBLink Parrot Settings

DO1KBL, Kim
 

Hello,
I have one Question. How i can configurate a HBLink master with Parrot in TG9990

I start hb_parrot.py and he repeat everythink.

Normal I have the Master on hblink.cfg on this master my frinds are connected with DVMega or openspot. its working without problem.
Now i will activate the Parrot in this network. When he made a group call to 9990 the Parrot will repeat. On all other groups he do nothing.

But I dont understand how i can made it.

Anyone can help me?

73,
Do1KBL

9161 - 9180 of 10057