Topics

Anyone taken the UDRC and connected it to a URI?

Michael J. Wolthuis
 

I am new to the UDRC, can the output on the 6 pin din be connected to a URI for interface to Allstar?

 

I read it says something about the CODEC is output?

 

Mike

Kb8zgl

 

 

 

Mike,

I guess you could, but I don't understand why you would?  The URI and UDRC are very similar in function, they contain a sound CODEC and access to GPIO pins to perform things like PTT.  

Allstar could be supported directly by the UDRC, connected to a radio, as long as Allstar could map the PTT pins and run directly on the Raspberry Pi.

On Tue, Sep 20, 2016 at 5:28 PM, Michael J. Wolthuis <wolthuis@...> wrote:

I am new to the UDRC, can the output on the 6 pin din be connected to a URI for interface to Allstar?

 

I read it says something about the CODEC is output?

 

Mike

Kb8zgl


--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223
   

Michael J. Wolthuis
 

John,

That would work also, has someone done the mapping for the pins yet for Allstar somehow?

 

I am basically looking for an easy interface to the DR-1x for Allstar, future digital potential.

 

Mike

 

 

From: <udrc@nw-digital-radio.groups.io> on behalf of John Hays <john@...>
Reply-To: <udrc@nw-digital-radio.groups.io>
Date: Tuesday, September 20, 2016 at 8:42 PM
To: <udrc@nw-digital-radio.groups.io>
Subject: Re: [udrc] Anyone taken the UDRC and connected it to a URI?

 

Mike,

 

I guess you could, but I don't understand why you would?  The URI and UDRC are very similar in function, they contain a sound CODEC and access to GPIO pins to perform things like PTT.  

 

Allstar could be supported directly by the UDRC, connected to a radio, as long as Allstar could map the PTT pins and run directly on the Raspberry Pi.

 

On Tue, Sep 20, 2016 at 5:28 PM, Michael J. Wolthuis <wolthuis@...> wrote:

I am new to the UDRC, can the output on the 6 pin din be connected to a URI for interface to Allstar?

 

I read it says something about the CODEC is output?

 

Mike

Kb8zgl

 

--

 


John D. Hays

K7VE

 

PO Box 1223, Edmonds, WA 98020-1223

   

 

 

AllStar would need to be ported to the Compass Linux system, which should be straight forward since its basically enhanced Raspbian Jesse, then PTT support would need to trigger a GPIO pin.

A couple of people have mentioned giving it a try, so maybe we will hear something.  If I can find the sources, I might give it a go :), when I get some spare time.


On Tue, Sep 20, 2016 at 6:10 PM, Michael J. Wolthuis <wolthuis@...> wrote:

John,

That would work also, has someone done the mapping for the pins yet for Allstar somehow?

 

I am basically looking for an easy interface to the DR-1x for Allstar, future digital potential.

 

Mike


--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223
   

 

This would be a good starting point for a developer -- https://github.com/N4IRS/AllStar


--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223
   

Steve N4IRS
 
Edited

As John said, The easiest way for AllStar to support the UDRC wiould be to bring up AllStar on Compass since the kernel module for the codec is not mainline (yet). At least I don't think it is.

I have a channel driver that I think would would work with the UDRC. The only thing I need to bring up AllStar on Compass, are the kernel headers so I can compile DAHDI. I'll look into it again when I get a little time.


73, Steve N4IRS 

Konrad Roeder -- WA4OSH
 
Edited

Steve,

It's been a while and now interest in Allstar is growing here in the Seattle area since the WW7PSR repeater is an AllstarLink node (#2462).  

Since AllstarLink.org is compiling the entire RPi-3 Image now for download, the Asterisk and the Allstar App are more and more tied into the "Santiago" and the "DMK Engineering" boards.  Is it still possible to get the separate pieces so that they can be compiled under different configurations (other than an RPI3 and the now somewhat crippled Beagle Bone black).  

I sure would like to see UDRC *replace* the URI board with it's 48/44.1 KHz sampling.  They for example are having difficulty in detecting/carrying FLDigi and/or Wolfram.  Is it possible to use one of the two codecs of the UDRC for AllStarLink and the other codec for decoding/encoding other complex modulations on the same audio channel and routing it over different path?  (This would be similar to the way VoIP systems carry FAX for example) ...all on the same board.

--Konrad, WA4OSH

 

Steve N4IRS
 

AllStarLink does support both pre-configured images and a method to add to a existing Debian install. Actually there is support for more then the CM1xx based sound devices. This weekend we restarted work on a UDRC based channel driver. I do NOT have a target date. We have been working on a updated channel driver method that will allow more configuration options. If you want to install AllStarLink on a existing Debian install, including the source code, take a look at https://github.com/AllStarLink/DIAL There is a script that will install and compile AllStarLink.

73, Steve N4IRS

Konrad Roeder -- WA4OSH
 

Steve,
I have one node, 46358, up and running on an RPi3 using the Arch Linux distro and the CM1?? based USB dongle I have.  I get audio, but have not modified the dongle for PTT and COR yet.

The other node, 46367, is in the middle of bring-up.  It's an RPI3 running AllStarLink Debian distro - RAT_RC1.  I have yet to get a CM1?? based audio dongle for it and configure it for the node number.

I have a third node, no Allstar node number requested yet.  It's an RPi3 with a UDRC-II board.  It currently has Compass running on it.  It runs FLDigi and Wolfram nicely. I have not installed Asterisk and app_rpt on it yet.  The goal of this node is to be a portable simplex AllStar "hotspot" that would allow me to use in locations that have an Internet connection via Wi-Fi or Ethernet.

--73, Konrad WA4OSH

On Mon, Jul 31, 2017 at 5:44 AM, Steve N4IRS <szingman@...> wrote:
AllStarLink does support both pre-configured images and a method to add to a existing Debian install. Actually there is support for more then the CM1xx based sound devices. This weekend we restarted work on a UDRC based channel driver. I do NOT have a target date. We have been working on a updated channel driver method that will allow more configuration options. If you want to install AllStarLink on a existing Debian install, including the source code, take a look at https://github.com/AllStarLink/DIAL There is a script that will install and compile AllStarLink.

73, Steve N4IRS




--
Best,
Konrad

Konrad Roeder
425-444-0595 Cell
425-256-2144 Home

Konrad Roeder -- WA4OSH
 

Steve,
P.S.   The reason I want to use the UDRC-II is so that I can run other protocols besides AllStar on the same pelican case, mainly Wolfram.

But it's occurred to me that there are many, many uses for a general purpose communications box .. for data and digital voice.  It also occurred to me that there are text to speech programs and virtual digital cables that can "patch" these programs together using the ALSA audio API and I2S interfaces.  This is part of the flexibility that the UDRC has and the AllStarLink has apparently missed altogether.  I think these changes would open up AllStar not only for hams, but for part 90 and 95? users as well.

I look forward to your UDRC based channel driver ... and perhaps an upgraded app_rpt so that it handles the ALSA interface better.  In the meantime I will get my two conventional nodes up and running.   I'm patient.

On Mon, Jul 31, 2017 at 9:05 AM, Konrad Roeder -- WA4OSH <konrad.roeder@...> wrote:
Steve,
I have one node, 46358, up and running on an RPi3 using the Arch Linux distro and the CM1?? based USB dongle I have.  I get audio, but have not modified the dongle for PTT and COR yet.

The other node, 46367, is in the middle of bring-up.  It's an RPI3 running AllStarLink Debian distro - RAT_RC1.  I have yet to get a CM1?? based audio dongle for it and configure it for the node number.

I have a third node, no Allstar node number requested yet.  It's an RPi3 with a UDRC-II board.  It currently has Compass running on it.  It runs FLDigi and Wolfram nicely. I have not installed Asterisk and app_rpt on it yet.  The goal of this node is to be a portable simplex AllStar "hotspot" that would allow me to use in locations that have an Internet connection via Wi-Fi or Ethernet.

--73, Konrad WA4OSH

On Mon, Jul 31, 2017 at 5:44 AM, Steve N4IRS <szingman@...> wrote:
AllStarLink does support both pre-configured images and a method to add to a existing Debian install. Actually there is support for more then the CM1xx based sound devices. This weekend we restarted work on a UDRC based channel driver. I do NOT have a target date. We have been working on a updated channel driver method that will allow more configuration options. If you want to install AllStarLink on a existing Debian install, including the source code, take a look at https://github.com/AllStarLink/DIAL There is a script that will install and compile AllStarLink.

73, Steve N4IRS




--
Best,
Konrad

Konrad Roeder
425-444-0595 Cell
425-256-2144 Home




--
Best,
Konrad

Konrad Roeder
425-444-0595 Cell
425-256-2144 Home

Steve N4IRS
 

Konrad,
Now would be a very good time to hear you comments on ALSA handling.

73, Steve

On 7/31/2017 12:26 PM, Konrad Roeder -- WA4OSH wrote:
I look forward to your UDRC based channel driver ... and perhaps an upgraded app_rpt so that it handles the ALSA interface better.

Konrad Roeder -- WA4OSH
 

Steve,
I have yet to setup an RPi3 using the stock DIAL distribution with the ALSA driver option.  I have not figured out how to run KDE or Gnome on that distribution.  Instead of driving a USB dongle, I should be able to drive an ALSA application like a sound mixer, tone generator and audio spectrum analyzer or an audio record/playback software.  I should be able to connect the two using a virtual audio cable.  I feel this would be the first steps in getting the UDRC-II board to run with AllStar.

--Konrad, WA4OSH

On Mon, Jul 31, 2017 at 9:37 AM, Steve N4IRS <szingman@...> wrote:
Konrad,
Now would be a very good time to hear you comments on ALSA handling.

73, Steve

On 7/31/2017 12:26 PM, Konrad Roeder -- WA4OSH wrote:
I look forward to your UDRC based channel driver ... and perhaps an upgraded app_rpt so that it handles the ALSA interface better.







--
Best,
Konrad

Konrad Roeder
425-444-0595 Cell
425-256-2144 Home

Steve N4IRS
 

Konrad,
AllStarLink (ASL) is primarily intended to connect directly to a radio. Yes, there is support for telephone interconnects. Not unusual considering ASL is built on a open source PBX. No matter if it is a URI or a PCI radio card, they are intended to connect directly to a radio. ASL was not built nor intended to use ALSA applications. The guiding design principle behind ASL was high quality audio. We felt the introduction of those things would turn ASL into EchoLink or IRLP. We have leveraged one of the channel drivers, chan_USRP which does allow us to send and receive PCM via UDP. This is what we used to build the DMR and D-Star bridges. There is also a channel driver to connect ASL to Echolink.

We will build a native ASL channel driver for the UDRC. It will look like any other channel driver to ASL. To work as intended, the UDRC will connect to a radio and provide a connection to the discriminator, modulator, COS and PTT. Optionally, it will also provide a method of sensing CTCSS from the receiver internal decoder. The existing chan_usbradio channel driver encodes and decodes CTCSS and provides pre-emphasis and  de-eemphasis and some audio shaping. We hope to be able to do the same thing with the UDRC.

You can install a GUI like KDE or Gnome on top of a ASL install. But this was not what ASL was designed to do. It is intended as a light weight repeater controller / VOIP interconnect. The ALSA channel driver was intended to allow someone to use the mic and a speaker of the PC to make a telephone call. You will notice there is no PTT signaling. If you want a GUI like Gnome or KDE, you might reverse your thinking. Add ASL to a existing GUI desktop.

73, Steve N4IRS           

On 08/01/2017 04:11 PM, Konrad Roeder -- WA4OSH wrote:
Steve,
I have yet to setup an RPi3 using the stock DIAL distribution with the ALSA driver option.  I have not figured out how to run KDE or Gnome on that distribution.  Instead of driving a USB dongle, I should be able to drive an ALSA application like a sound mixer, tone generator and audio spectrum analyzer or an audio record/playback software.  I should be able to connect the two using a virtual audio cable.  I feel this would be the first steps in getting the UDRC-II board to run with AllStar.

--Konrad, WA4OSH

On Mon, Jul 31, 2017 at 9:37 AM, Steve N4IRS <szingman@...> wrote:
Konrad,
Now would be a very good time to hear you comments on ALSA handling.

73, Steve

On 7/31/2017 12:26 PM, Konrad Roeder -- WA4OSH wrote:
I look forward to your UDRC based channel driver ... and perhaps an upgraded app_rpt so that it handles the ALSA interface better.







--
Best,
Konrad

Konrad Roeder
425-444-0595 Cell
425-256-2144 Home

Konrad Roeder -- WA4OSH
 

Steve,
I waited a bit before responding to you.  First of all, I don't want to brag or come off brash.  Just to let you know, I worked on the first full-duplex Land-Mobile trunking radios in the very early 1990's and have a very good understanding of Voice over IP.  I have been working all my life in the interface between radio transceivers and various forms of voice and data applications.  I understand RPi, Linux, RF, etc.  I'm involved with military communications currently in my professional life.

Yes, I of course I understand that AllStarLink (ASL) was *primarily intended* to connect directly to a radio through Asterisk, an open source VoIP PBX.  The real beauty here is the *full duplex* Asterisk VoIP core and being able to interface to radios through a USB-based interface, the URI.  Other boards have been built to provide simulcast interfaces for linking repeaters.  But things sometimes are such a great idea that they can grow beyond what they were initially intended to be.

I also understand that you intend on building a channel driver so that the Asterisk VoIP PBX can talk to a massively superior interface directly from the Raspberry Pi's GPIO bus instead of being constrained by a USB interface.  I can see how it will give you direct control over the COR, the PTT and the CTCSS encode/decode. Please note that I have bought a UDRC-II and have used it in a number of experiments and see the huge potential for the Asterisk channel driver.   I think it deserves a complementary name to Asterisk ... Obelisk.  I'm patiently waiting.

Besides the app_rpt, the AllStarLink applications and hopefully the UDRC-II interface, there are many other modules that can be used to interface Asterisk, including an ALSA interface and the SIP interface.

Yes, I understand the primary reason for the ALSA interface.  I have explored it in the last six months, looking at all sorts of ways of interfacing sound boards, audio filters, FFT's, etc. etc.  A lot of these require a GUI interface in order to make use of them.  This was my primary interest in bringing up a GUI.

I'm also very interested in the SIP interface, which essentially means that you can have a Cisco 79xx phone reflashed for SIP, or something like a Grandstream 701 phone adapter to a POTS phone connected to a vast ham radio / VoIP network.  The possibilities are really astounding.

I want you to know that I fully understand the potential of a UDRC-II board interfaced with Asterisk can mean.  For example, An Asterisk VOIP PBX can host Analog, D-Star, DMR, Fusion, Single Sideband, etc. users all on one conference bridge or "reflector".  Asterisk also serves voicemail and phone trees (IVR) and connections to services that we have not invented yet.  Think of it as the central Rosetta stone that can join these dissimilar networks together.  The UDRC-II is far superior to the USB-based boards out there today due to its onboard DSP and the DAC/ADCs.  It's a great interface for digital radios, but it has not been put to the task of interfacing to a VoIP PBX yet.  I get it.

This has applications far beyond ham radio, especially when serving Part 90 and 95 communities.  They've never been able to talk with each other before.

My two cents ...
--Konrad, WA4OSH



On Tue, Aug 1, 2017 at 4:23 PM, Steve N4IRS <szingman@...> wrote:
Konrad,
AllStarLink (ASL) is primarily intended to connect directly to a radio. Yes, there is support for telephone interconnects. Not unusual considering ASL is built on a open source PBX. No matter if it is a URI or a PCI radio card, they are intended to connect directly to a radio. ASL was not built nor intended to use ALSA applications. The guiding design principle behind ASL was high quality audio. We felt the introduction of those things would turn ASL into EchoLink or IRLP. We have leveraged one of the channel drivers, chan_USRP which does allow us to send and receive PCM via UDP. This is what we used to build the DMR and D-Star bridges. There is also a channel driver to connect ASL to Echolink.

We will build a native ASL channel driver for the UDRC. It will look like any other channel driver to ASL. To work as intended, the UDRC will connect to a radio and provide a connection to the discriminator, modulator, COS and PTT. Optionally, it will also provide a method of sensing CTCSS from the receiver internal decoder. The existing chan_usbradio channel driver encodes and decodes CTCSS and provides pre-emphasis and  de-eemphasis and some audio shaping. We hope to be able to do the same thing with the UDRC.

You can install a GUI like KDE or Gnome on top of a ASL install. But this was not what ASL was designed to do. It is intended as a light weight repeater controller / VOIP interconnect. The ALSA channel driver was intended to allow someone to use the mic and a speaker of the PC to make a telephone call. You will notice there is no PTT signaling. If you want a GUI like Gnome or KDE, you might reverse your thinking. Add ASL to a existing GUI desktop.

73, Steve N4IRS           

On 08/01/2017 04:11 PM, Konrad Roeder -- WA4OSH wrote:
Steve,
I have yet to setup an RPi3 using the stock DIAL distribution with the ALSA driver option.  I have not figured out how to run KDE or Gnome on that distribution.  Instead of driving a USB dongle, I should be able to drive an ALSA application like a sound mixer, tone generator and audio spectrum analyzer or an audio record/playback software.  I should be able to connect the two using a virtual audio cable.  I feel this would be the first steps in getting the UDRC-II board to run with AllStar.

--Konrad, WA4OSH

On Mon, Jul 31, 2017 at 9:37 AM, Steve N4IRS <szingman@...> wrote:
Konrad,
Now would be a very good time to hear you comments on ALSA handling.

73, Steve

On 7/31/2017 12:26 PM, Konrad Roeder -- WA4OSH wrote:
I look forward to your UDRC based channel driver ... and perhaps an upgraded app_rpt so that it handles the ALSA interface better.







--
Best,
Konrad

Konrad Roeder
425-444-0595 Cell
425-256-2144 Home




--
Best,
Konrad

Konrad Roeder
425-444-0595 Cell
425-256-2144 Home

Steve N4IRS
 



On 08/03/2017 05:24 AM, Konrad Roeder -- WA4OSH wrote:
Steve,
I waited a bit before responding to you.  First of all, I don't want to brag or come off brash.  Just to let you know, I worked on the first full-duplex Land-Mobile trunking radios in the very early 1990's and have a very good understanding of Voice over IP.  I have been working all my life in the interface between radio transceivers and various forms of voice and data applications.  I understand RPi, Linux, RF, etc.  I'm involved with military communications currently in my professional life.

Yes, I of course I understand that AllStarLink (ASL) was *primarily intended* to connect directly to a radio through Asterisk, an open source VoIP PBX.  The real beauty here is the *full duplex* Asterisk VoIP core and being able to interface to radios through a USB-based interface, the URI.  Other boards have been built to provide simulcast interfaces for linking repeaters.  But things sometimes are such a great idea that they can grow beyond what they were initially intended to be.
Yes, ASL supports simulcast and receiver voting.

I also understand that you intend on building a channel driver so that the Asterisk VoIP PBX can talk to a massively superior interface directly from the Raspberry Pi's GPIO bus instead of being constrained by a USB interface.  I can see how it will give you direct control over the COR, the PTT and the CTCSS encode/decode. Please note that I have bought a UDRC-II and have used it in a number of experiments and see the huge potential for the Asterisk channel driver.   I think it deserves a complementary name to Asterisk ... Obelisk.  I'm patiently waiting.
Not sure what you are renaming. it will simply be chan_udrc

Besides the app_rpt, the AllStarLink applications and hopefully the UDRC-II interface, there are many other modules that can be used to interface Asterisk, including an ALSA interface and the SIP interface.

Yes, I understand the primary reason for the ALSA interface.  I have explored it in the last six months, looking at all sorts of ways of interfacing sound boards, audio filters, FFT's, etc. etc.  A lot of these require a GUI interface in order to make use of them.  This was my primary interest in bringing up a GUI.

I'm also very interested in the SIP interface, which essentially means that you can have a Cisco 79xx phone reflashed for SIP, or something like a Grandstream 701 phone adapter to a POTS phone connected to a vast ham radio / VoIP network.  The possibilities are really astounding.
We have been connecting sip phones to ASL for years. ASL also supports IOS and Android apps.

I want you to know that I fully understand the potential of a UDRC-II board interfaced with Asterisk can mean.  For example, An Asterisk VOIP PBX can host Analog, D-Star, DMR, Fusion, Single Sideband, etc. users all on one conference bridge or "reflector".  Asterisk also serves voicemail and phone trees (IVR) and connections to services that we have not invented yet.  Think of it as the central Rosetta stone that can join these dissimilar networks together.  The UDRC-II is far superior to the USB-based boards out there today due to its onboard DSP and the DAC/ADCs.  It's a great interface for digital radios, but it has not been put to the task of interfacing to a VoIP PBX yet.  I get it.

This has applications far beyond ham radio, especially when serving Part 90 and 95 communities.  They've never been able to talk with each other before.
Ah, not sure what you mean that they have not been able to talk to each other.

My two cents ...
--Konrad, WA4OSH

I await the totally awesome applications.

73, Steve N4IRS




On Tue, Aug 1, 2017 at 4:23 PM, Steve N4IRS <szingman@...> wrote:
Konrad,
AllStarLink (ASL) is primarily intended to connect directly to a radio. Yes, there is support for telephone interconnects. Not unusual considering ASL is built on a open source PBX. No matter if it is a URI or a PCI radio card, they are intended to connect directly to a radio. ASL was not built nor intended to use ALSA applications. The guiding design principle behind ASL was high quality audio. We felt the introduction of those things would turn ASL into EchoLink or IRLP. We have leveraged one of the channel drivers, chan_USRP which does allow us to send and receive PCM via UDP. This is what we used to build the DMR and D-Star bridges. There is also a channel driver to connect ASL to Echolink.

We will build a native ASL channel driver for the UDRC. It will look like any other channel driver to ASL. To work as intended, the UDRC will connect to a radio and provide a connection to the discriminator, modulator, COS and PTT. Optionally, it will also provide a method of sensing CTCSS from the receiver internal decoder. The existing chan_usbradio channel driver encodes and decodes CTCSS and provides pre-emphasis and  de-eemphasis and some audio shaping. We hope to be able to do the same thing with the UDRC.

You can install a GUI like KDE or Gnome on top of a ASL install. But this was not what ASL was designed to do. It is intended as a light weight repeater controller / VOIP interconnect. The ALSA channel driver was intended to allow someone to use the mic and a speaker of the PC to make a telephone call. You will notice there is no PTT signaling. If you want a GUI like Gnome or KDE, you might reverse your thinking. Add ASL to a existing GUI desktop.

73, Steve N4IRS           

On 08/01/2017 04:11 PM, Konrad Roeder -- WA4OSH wrote:
Steve,
I have yet to setup an RPi3 using the stock DIAL distribution with the ALSA driver option.  I have not figured out how to run KDE or Gnome on that distribution.  Instead of driving a USB dongle, I should be able to drive an ALSA application like a sound mixer, tone generator and audio spectrum analyzer or an audio record/playback software.  I should be able to connect the two using a virtual audio cable.  I feel this would be the first steps in getting the UDRC-II board to run with AllStar.

--Konrad, WA4OSH

On Mon, Jul 31, 2017 at 9:37 AM, Steve N4IRS <szingman@...> wrote:
Konrad,
Now would be a very good time to hear you comments on ALSA handling.

73, Steve

On 7/31/2017 12:26 PM, Konrad Roeder -- WA4OSH wrote:
I look forward to your UDRC based channel driver ... and perhaps an upgraded app_rpt so that it handles the ALSA interface better.







--
Best,
Konrad

Konrad Roeder
425-444-0595 Cell
425-256-2144 Home




--
Best,
Konrad

Konrad Roeder
425-444-0595 Cell
425-256-2144 Home

Konrad Roeder -- WA4OSH
 

Steve wrote --- Ah, not sure what you mean that they have not been able to talk to each other.

I don't see very many "reflectors" or conference bridges advertised to bridge for example D-Star with analog repeaters.  Maybe I'm not that observant.

--Konrad, WA4OSH

On Thu, Aug 3, 2017 at 3:03 AM, Steve N4IRS <szingman@...> wrote:


On 08/03/2017 05:24 AM, Konrad Roeder -- WA4OSH wrote:
Steve,
I waited a bit before responding to you.  First of all, I don't want to brag or come off brash.  Just to let you know, I worked on the first full-duplex Land-Mobile trunking radios in the very early 1990's and have a very good understanding of Voice over IP.  I have been working all my life in the interface between radio transceivers and various forms of voice and data applications.  I understand RPi, Linux, RF, etc.  I'm involved with military communications currently in my professional life.

Yes, I of course I understand that AllStarLink (ASL) was *primarily intended* to connect directly to a radio through Asterisk, an open source VoIP PBX.  The real beauty here is the *full duplex* Asterisk VoIP core and being able to interface to radios through a USB-based interface, the URI.  Other boards have been built to provide simulcast interfaces for linking repeaters.  But things sometimes are such a great idea that they can grow beyond what they were initially intended to be.
Yes, ASL supports simulcast and receiver voting.

I also understand that you intend on building a channel driver so that the Asterisk VoIP PBX can talk to a massively superior interface directly from the Raspberry Pi's GPIO bus instead of being constrained by a USB interface.  I can see how it will give you direct control over the COR, the PTT and the CTCSS encode/decode. Please note that I have bought a UDRC-II and have used it in a number of experiments and see the huge potential for the Asterisk channel driver.   I think it deserves a complementary name to Asterisk ... Obelisk.  I'm patiently waiting.
Not sure what you are renaming. it will simply be chan_udrc

Besides the app_rpt, the AllStarLink applications and hopefully the UDRC-II interface, there are many other modules that can be used to interface Asterisk, including an ALSA interface and the SIP interface.

Yes, I understand the primary reason for the ALSA interface.  I have explored it in the last six months, looking at all sorts of ways of interfacing sound boards, audio filters, FFT's, etc. etc.  A lot of these require a GUI interface in order to make use of them.  This was my primary interest in bringing up a GUI.

I'm also very interested in the SIP interface, which essentially means that you can have a Cisco 79xx phone reflashed for SIP, or something like a Grandstream 701 phone adapter to a POTS phone connected to a vast ham radio / VoIP network.  The possibilities are really astounding.
We have been connecting sip phones to ASL for years. ASL also supports IOS and Android apps.

I want you to know that I fully understand the potential of a UDRC-II board interfaced with Asterisk can mean.  For example, An Asterisk VOIP PBX can host Analog, D-Star, DMR, Fusion, Single Sideband, etc. users all on one conference bridge or "reflector".  Asterisk also serves voicemail and phone trees (IVR) and connections to services that we have not invented yet.  Think of it as the central Rosetta stone that can join these dissimilar networks together.  The UDRC-II is far superior to the USB-based boards out there today due to its onboard DSP and the DAC/ADCs.  It's a great interface for digital radios, but it has not been put to the task of interfacing to a VoIP PBX yet.  I get it.

This has applications far beyond ham radio, especially when serving Part 90 and 95 communities.  They've never been able to talk with each other before.
Ah, not sure what you mean that they have not been able to talk to each other.

My two cents ...
--Konrad, WA4OSH

I await the totally awesome applications.

73, Steve N4IRS




On Tue, Aug 1, 2017 at 4:23 PM, Steve N4IRS <szingman@...> wrote:
Konrad,
AllStarLink (ASL) is primarily intended to connect directly to a radio. Yes, there is support for telephone interconnects. Not unusual considering ASL is built on a open source PBX. No matter if it is a URI or a PCI radio card, they are intended to connect directly to a radio. ASL was not built nor intended to use ALSA applications. The guiding design principle behind ASL was high quality audio. We felt the introduction of those things would turn ASL into EchoLink or IRLP. We have leveraged one of the channel drivers, chan_USRP which does allow us to send and receive PCM via UDP. This is what we used to build the DMR and D-Star bridges. There is also a channel driver to connect ASL to Echolink.

We will build a native ASL channel driver for the UDRC. It will look like any other channel driver to ASL. To work as intended, the UDRC will connect to a radio and provide a connection to the discriminator, modulator, COS and PTT. Optionally, it will also provide a method of sensing CTCSS from the receiver internal decoder. The existing chan_usbradio channel driver encodes and decodes CTCSS and provides pre-emphasis and  de-eemphasis and some audio shaping. We hope to be able to do the same thing with the UDRC.

You can install a GUI like KDE or Gnome on top of a ASL install. But this was not what ASL was designed to do. It is intended as a light weight repeater controller / VOIP interconnect. The ALSA channel driver was intended to allow someone to use the mic and a speaker of the PC to make a telephone call. You will notice there is no PTT signaling. If you want a GUI like Gnome or KDE, you might reverse your thinking. Add ASL to a existing GUI desktop.

73, Steve N4IRS           

On 08/01/2017 04:11 PM, Konrad Roeder -- WA4OSH wrote:
Steve,
I have yet to setup an RPi3 using the stock DIAL distribution with the ALSA driver option.  I have not figured out how to run KDE or Gnome on that distribution.  Instead of driving a USB dongle, I should be able to drive an ALSA application like a sound mixer, tone generator and audio spectrum analyzer or an audio record/playback software.  I should be able to connect the two using a virtual audio cable.  I feel this would be the first steps in getting the UDRC-II board to run with AllStar.

--Konrad, WA4OSH

On Mon, Jul 31, 2017 at 9:37 AM, Steve N4IRS <szingman@...> wrote:
Konrad,
Now would be a very good time to hear you comments on ALSA handling.

73, Steve

On 7/31/2017 12:26 PM, Konrad Roeder -- WA4OSH wrote:
I look forward to your UDRC based channel driver ... and perhaps an upgraded app_rpt so that it handles the ALSA interface better.







--
Best,
Konrad

Konrad Roeder
425-444-0595 Cell
425-256-2144 Home




--
Best,
Konrad

Konrad Roeder
425-444-0595 Cell
425-256-2144 Home




--
Best,
Konrad

Konrad Roeder
425-444-0595 Cell
425-256-2144 Home

Previous Topic Next Topic