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


 

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


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




Steven Blackford
 

Steve,
  Tnanks for the update & all the hard work by everyone involved!  As you know already, over the past several months one of my big projects has been the Carolina Link and without a lot of the software you guys provide, the task would've been a lot harder to do.  It's mostly streamlined now that we are taking advantage of the tanscoding system with the XLXD Reflector, but there are times I can honestly say while it works great, the DMR<->D-Star bridge solution you guys provide is 100 times more flexible.  Our group had actually started to get used to this & I still think @ times would prefer if I put this solution back in place. :-)  I continue to  provide a bridge between AllStar and D-Star.  After my presentation at both the GARA Club in Greensboro, NC and the Charlotte Hamfest this month, we've seen a lot more interest in what we're doing locally and in AllStar as well.  Besides our bridge, I provide an additional AllStar node our members can use to connect to other Allstar Nodes via the Android IAXRPT app & Zoiper.  Before my presentations, we maybe had 2-3 people taking advantage of this.  Now we have several people using it.  So, thanks again for all the hard work & 73 de K4SQI!

Steve, K4SQI


On Wed, Mar 21, 2018 at 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






--
-----
Steve, kb7sqi@...


Matthew 2E0SIP
 

Hi All,

This is an exciting update, thanks to all for the hard work.

One question, will the emulator run as a separate process, so it can be emulated on X86_64, without running Analog_Bridge in its entirety in an emulator? 

Cheers


Steve N4IRS
 

Yes it will. The plan is to decouple to Vocoders from Analog_Bridge and provide a method for someone to build the Vocoder separately.

On 4/5/2018 8:57 AM, Matthew 2E0SIP wrote:

Hi All,

This is an exciting update, thanks to all for the hard work.

One question, will the emulator run as a separate process, so it can be emulated on X86_64, without running Analog_Bridge in its entirety in an emulator? 

Cheers



James Riley kb9tzq
 

Just wondering how do I get the dvswitch toolkit I am interested in doing p25<>dmr and nxdn<>dmr


Steve N4IRS
 

James,
We are a few days away from the alpha release of the new programs MMDVM_Bridge and Quantar_Bridge. We will also release a alpha of Analog_Bridge that you will need to do P25 <---> DMR. We have been testing the P25 bridge on TG 31665 and do not expect any issues.

73, Steve N4IRS

On 4/12/2018 11:47 PM, James Riley kb9tzq wrote:
Just wondering how do I get the dvswitch toolkit I am interested in doing p25<>dmr and nxdn<>dmr


J P Watters <kc9kko@...>
 

Steve N4IRS,

That is pretty cool news, since both myself and our local club are using Quantar's.

..jpw


Steve N4IRS
 

OK, that IS interesting. We are using the configuration that is the same as P25NX. A V.24 board and a Cisco router. Quantar_Bridge allow you to use a Quantar P25 native on the MMDVM P25 Network. No MMDVM board required.

Steve N4IRS

On 4/13/2018 11:10 AM, J P Watters wrote:
Steve N4IRS,

That is pretty cool news, since both myself and our local club are using Quantar's.

..jpw


J P Watters <kc9kko@...>
 

Steve N4IRS,

Now you really have my attention. I have a pair of V.24 boards(P25NX version). Where do I find out how to configure things for the "MMDVM P25 Network". The P25NX network configuration seemed complicated to the point of questioning how reliable it would be. 

I will have to look at the version of the dual ethernet cisco router that I have on the scrap heap. It came out of a new fiber node a couple of years ago that was that was installed and decommissioned after a month. 

I have a APX portable that I have to keep handy for the public service side of life. P25 phase 2 rollout that was scheduled for last march, still in the going to roll out mode.  This would allow me to program a configuration for our UHF quantar repeater and link it to DMR talk groups.

WOW, one radio, for work and hobby.  And 0xFE receive for everybody!!!

..jpw
KC9KKO
Morris, IL





Steve N4IRS
 

JP,
The Quantar is a great repeater for analog and P25. The work David and others did to extract the data from the Quantar really helped everybody move thing along with networking Quantars. The thing that bothered us was no support for anything other then a Quantar like repeater. The MMDVM P25 network is continuing to grow. With support for home brew repeaters and hot spots, new people are getting on daily. Are all signals perfect? Heck no! I'm not enough of a purest to worry about that too much.

What we did, was leverage the work P25NX did to extract the P25 frames from the Quantar using the Cisco router. Instead of sending that data via VPN to one of the P25NX reflectors, we package up the P25 frames as a MMDVM would like to see them and send them on to a MMDM P25 reflector. It's quite simple in it's application.  The one thing people need to understand is that this is P25 ONLY. That is not to say Quantar_Bridge could not be connected to one of the other _Bridge programs to connect to a DMR, NXDN, or YSF narrow network. For the best audio quality, we feel either stay P25 or YSF wide, since they are both IMBE and not transcoding is required.

As for the Cisco router, you need support for tunneling the serial data. The STUN data is sent to a connected host where the IMBE is extracted and re-packaged. I won't recreate the great documentation P25NX did on setting up the Quantar and Router but I will post links to the forums where the discussion is happening. BTW, I'm no Cisco expert, I can spell enable... I think we can simplify some of the configuration P25NX does to the Cisco just to make it easier to understand.

73, Steve N4IRS

 

On 4/13/2018 11:27 AM, J P Watters wrote:
Steve N4IRS,

Now you really have my attention. I have a pair of V.24 boards(P25NX version). Where do I find out how to configure things for the "MMDVM P25 Network". The P25NX network configuration seemed complicated to the point of questioning how reliable it would be. 

I will have to look at the version of the dual ethernet cisco router that I have on the scrap heap. It came out of a new fiber node a couple of years ago that was that was installed and decommissioned after a month. 

I have a APX portable that I have to keep handy for the public service side of life. P25 phase 2 rollout that was scheduled for last march, still in the going to roll out mode.  This would allow me to program a configuration for our UHF quantar repeater and link it to DMR talk groups.

WOW, one radio, for work and hobby.  And 0xFE receive for everybody!!!

..jpw
KC9KKO
Morris, IL






James Riley kb9tzq
 

Thanks Steve for everything you guys do and keep up the job hopefully I will have a nxdn talkgroup on mmdvm this weekend and I think I have my p25 talkgroup up and going once you guys come out with the toolkit I will be ready