Date   

Re: Retaking on the ASL<->YSF personal project #mmdvm_bridge #analog_bridge

Tito Lopez - YN1OB
 

Well I tried it but failed miserably.
Anyone willing to lend a hand wanting to login to the node adn check that crap out. I am sure its something simple but ysf never seems to work when trying to configured the darn thing. No audio coming across
Any takers? please let me know.
YN1OB


Re: Retaking on the ASL<->YSF personal project #mmdvm_bridge #analog_bridge

Steve N4IRS
 

Yes

Sent by smoke signal (AT&T)


From: DVSwitch-ASL@DVSwitch.groups.io <DVSwitch-ASL@DVSwitch.groups.io> on behalf of Tito Lopez <OBUSTOS01@...>
Sent: Wednesday, March 11, 2020 3:58:46 PM
To: DVSwitch-ASL@DVSwitch.groups.io <DVSwitch-ASL@DVSwitch.groups.io>
Subject: Re: [DVSwitch-ASL] Retaking on the ASL<->YSF personal project #mmdvm_bridge #analog_bridge
 
One last question, do I need that USRP in the "1999" Stanza?
Orlando w3daw


Re: Retaking on the ASL<->YSF personal project #mmdvm_bridge #analog_bridge

Tito Lopez - YN1OB
 

One last question, do I need that USRP in the "1999" Stanza?
Orlando w3daw


Re: Retaking on the ASL<->YSF personal project #mmdvm_bridge #analog_bridge

Steve N4IRS
 

Pretty much disable DMR and enable YSF in MMDVM_Bridge.ini
Set the ports for YSF in DVSwitch.ini to match the ports for DMR (TX and RX)

Steve N4IRS

On 3/10/2020 7:52 PM, Tito Lopez wrote:
I have been away from the groups for a few months now and would like to restart the project in which I would like to bridge ASL to YSFN strictly.
I have both fresh installs of Allstarlink and YSF reflector. Both running on vultr provider.
Since I have the YSFReflector running on a separate machine I need to start with Allstarlink.
Allstarlink is up and running with echolink enabled which is running fine.
I see that there are write ups to to ASL-DMR but my fav is YSF.
Let me know what I need to do to get that working.
 Thanks to all those who take time to point me out in the right direction.
W3DAW


Retaking on the ASL<->YSF personal project #mmdvm_bridge #analog_bridge

Tito Lopez - YN1OB
 

I have been away from the groups for a few months now and would like to restart the project in which I would like to bridge ASL to YSFN strictly.
I have both fresh installs of Allstarlink and YSF reflector. Both running on vultr provider.
Since I have the YSFReflector running on a separate machine I need to start with Allstarlink.
Allstarlink is up and running with echolink enabled which is running fine.
I see that there are write ups to to ASL-DMR but my fav is YSF.
Let me know what I need to do to get that working.
 Thanks to all those who take time to point me out in the right direction.
W3DAW


Re: USPR and GPIO (4 wire analog interface) to P25 #analog_bridge #mmdvm_bridge

Ed W8VT
 

What is the proper way to compile and install new modules like Stacy's ASL_GPIO and dealing with menuselect and all that fun stuff?

Thanks,
Ed W8VT


Re: USPR and GPIO (4 wire analog interface) to P25 #analog_bridge #mmdvm_bridge

SP2ONG Waldek
 

Hi Steve,

It will be nice to see chan_alsaradio in ASL which be allow better interact ASL with external applications via ASLA loop pseudo sound card
and have possible use PTY device to PTT and COS too.

73 Waldek


USPR and GPIO (4 wire analog interface) to P25 #analog_bridge #mmdvm_bridge

Steve N4IRS
 

Tim,
That's good to hear. I knew Stacy had forked the ASL_GPIO repo. I have added the channel drivers from that repo to <https://github.com/DVSwitch/Asterisk/tree/Channel-Drivers> which is a work in progress. In the long run we want to get away from the dependency on OSS and move to ALSA. The DVSwitch repo is where we are working to enhance the ASL to DVSwitch connectivity.

As to the mode change, We have moved on from swapping .ini files to a method to tell AB to switch modes on the fly. See <https://github.com/DVSwitch/Analog_Bridge> Everything is done by dvswitch.sh and is executed by dvsm.macro.

For the Dashboard, I have been working (on my stack of round to it) on <https://github.com/DVSwitch/MMDVMHost-Dashboard> which is nothing but a hack to the existing MMDVMHost dashboard. MMDVM_Bridge will be getting changes to the logging output so that the dashboard can better scrape the log. That is unless we move to something more robust like a stream from MB to the dashboard and bypass the need for log scraping.

Steve N4IRS 

On 1/23/2020 8:22 AM, Tim VK3TIM wrote:
Hi Steve,
I have a  ASL node setup with
"First node" using the modified simpleusb drivers " I think you may have originally setup ASL_GPIO_Master" that was later forked (https://github.com/KG7QIN/ASL_GPIO) .
This allows the use of Pi GPIOs for the analog PTT and COS audio via a CM108 sound card -"4 wire E&M." - "I use a customised Pi Hat for this."
"Second node" is using USRP to Analog Bridge.
"First node" Using DTMF scripts in ASL for the *Tune.sh commands for the Mode change and the TG changes much similar to your original DVswitch approach with multiple .ini files.
At this stage all seems to be working well.
I did notice when activating a "mode" change command that the analog bridge service had to be restarted three times in the script when making the changes to the analog_bridge.ini  copying them to temp and then copying back to the opt/Analog_bridge directory or it would sometimes get stuck - This also happened to me on the original USRP controls using DVswitch (it also meant that with every "mode" change I had to register again but that didn't worry me.)
- What i am looking into now is a user dashboard to see what the Modes and Talkgroups are actually on visually and possibly  audio commands back over the "First Node"

(I think I am already in that group will take a look.) 
Thanks for all your great work.
Tim 
VK3TIM





Re: DAHDI timing and ASL

Steve N4IRS
 
Edited

I have posted a updated version of DAHDI source. It will build on the toolchain shipped with Raspbian Buster. I still need to test it with other architectures.
I can build a DKMS with this also so I will be replacing the apt package. More testing to do.
Repo is at https://github.com/DVSwitch/asl-dahdi-linux

Build on Stretch i386
Build on Jessie x64

Steve N4IRS


Re: DAHDI timing and ASL

Ken KE2N
 

my big linux box 

 Version: Intel(R) Core(TM) i5-4690K CPU @ 3.50GHz
        Voltage: 1.2 V
        External Clock: 100 MHz
        Max Speed: 3800 MHz
        Current Speed: 3500 MHz

root@xlxref:/usr/sbin# sudo dahdi_test -c 100 Opened pseudo dahdi interface, measuring accuracy...

99.997% 99.996% 99.999% 99.998% 99.995% 99.997% 99.999% 99.998% 99.999% 99.997% 99.998% 99.999% 100.000% 99.999% 99.997% 99.999% 99.998% 99.998% 99.998% 99.998% 100.000% 99.998% 99.999% 99.999% 99.996% 99.998% 99.998% 99.999% 99.999% 99.997% 100.000% 99.998% 99.998% 99.999% 99.997% 99.218% 99.216% 99.998% 99.224% 99.999% 99.221% 99.998% 99.220% 99.995% 99.219% 99.999% 99.999% 99.224% 99.218% 99.223% 99.222% 99.999% 99.996% 99.997% 99.999% 99.998% 100.000% 99.995% 99.224% 99.221% 99.999% 99.998% 99.998% 99.999% 99.998% 99.998% 99.999% 99.997% 99.223% 99.222% 99.998% 99.998% 99.999% 100.000% 99.997% 99.998% 99.998% 99.995% 99.224% 99.222% 99.997% 99.998% 99.999% 99.224% 99.221% 99.999% 99.999% 99.999% 99.225% 99.221% 99.998% 99.999% 99.998% 99.224% 99.221% 99.999% 99.998% 99.221%

--- Results after 98 passes ---

Best: 100.000% -- Worst: 99.216% -- Average: 99.815911% Cumulative Accuracy (not per pass): 99.994 root@xlxref:/usr/sbin#

 

 

root@xlxref:/usr/src/asl-dahdi-linux-2.11.1# /usr/sbin/dahdi_test -c 100 Opened pseudo dahdi interface, measuring accuracy...

99.995% 99.996% 99.999% 99.999% 99.997% 99.998% 99.995% 100.000% 99.998% 99.997% 99.997% 99.995% 99.999% 99.999% 99.997% 100.000% 99.999% 99.995% 99.998% 100.000% 99.996% 99.999% 99.995% 99.997% 99.999% 99.998% 99.995% 100.000% 100.000% 100.000% 99.997% 99.995% 100.000% 100.000% 99.997% 100.000% 99.997% 99.997% 99.997% 100.000% 99.998% 99.996% 99.999% 99.999% 100.000% 99.994% 99.998% 99.999% 99.997% 99.997% 99.998% 99.995% 99.999% 99.997% 99.997% 99.998% 99.995% 99.997% 99.998% 99.998% 99.999% 99.995% 99.998% 99.998% 100.000% 99.996% 99.997% 99.997% 99.999% 99.997% 99.998% 99.999% 99.997% 99.998% 100.000% 99.995% 99.999% 99.999% 99.999% 99.997% 99.997% 99.995% 99.997% 99.998% 99.998% 100.000% 99.995% 99.999% 100.000% 100.000% 99.996% 99.999% 99.997% 99.998% 100.000% 99.997% 99.995% 99.998%

--- Results after 98 passes ---

Best: 100.000% -- Worst: 99.994% -- Average: 99.997719% Cumulative Accuracy (not per pass): 99.999





Re: DAHDI timing and ASL

Ken KE2N
 

Thanks for the insight Tim.
I wonder if there is some sort of "elastic buffer" feeding into the FOB?


Re: DAHDI timing and ASL

Tim WD6AWP
 

HV did a fix where idle data is set to the URI constantly. You can see this in that the green LED behaves differently in HV nodes vs ASL. David said that helps with delayed audio causing the "hear yourself echo" on repeaters. I’ve never heard that it fixed a stuttering ID on FOB startup. 

A similar symptom is a startup stutter from connected nodes at first transmissions. I’ve always assumed that is the IAX jitter buffers adjusting from the relaxed value (40ms) to something larger as needed. 
--
Tim
:wq

On Dec 30, 2019, at 10:47 AM, Steve N4IRS <szingman@...> wrote:

Ken,
Not sure what you mean by running the data stream continuously. I'm thinking a startup delay may help, but both seem like a hack rather then a fix. What channel driver are you seeing this with?

Steve N4IRS

On 12/30/19 1:43 PM, Ken KE2N via Groups.Io wrote:
This (dahdi_dummy) worked well with my RPI3 and it even helped results on a big hulking quad core machine, by raising the occasional worst-case result..

The remaining problem that I see with ASL1.01 is - for lack of a better name - usb fob startup.  When the repeater has been quiet and decides to spit out a morse or voice ID, sometimes the first morse character or the first syllable or two of the voice comes out choppy. 

In the other camp I believe they fixed this problem by running the data stream continuously, is that hard to do?

Ken




--
Tim
:wq


Re: fob startup - was: DAHDI timing and ASL

Steve N4IRS
 

Ken,
Thanks for Googleing that for me. ;) We have a list of bugs (and fixes) I'll see if I can correlate. If not, I'll add it. Since most of the changes are not published, any info would help.

Steve

On 12/30/19 3:59 PM, Ken KE2N via Groups.Io wrote:
My experience is with the usbradio channel. Not sure if it will happen with simple usb.

The "fix" could be a hack as you say.  Although, if the hardware requires it ... then you might say it's a feature ;-)

To me it seems like some pipeline underflows, or overflows, right at the start.  My observation is that it happens when ASL tries to key up the radio and talk ... essentially at the same time.  It does not happen *every* time.  But I heard the effect three times in a short while after starting the repeater up last night.  And I think I heard one chopped up CW ID today sometime. Once the audio gets going, it's fine.

People whose radios are slow to open the squelch will never have heard this.  They will also never have heard the first letter of the repeater ID on a cold key-up (and probably don't care anyway).

Doing a Google search I am reminded that this fix was for simple usb (I do not know if it is applicable to usbradio - as you know, that driver is not favored in the other flavor of asterisk controller).

Re-reading the text below (which google just found for me), this fix was actually intended for another problem. Although it might also fix the issue I am talking about.

... the simpleusb driver continues
> to send frames of silence to the audio adapter at all times; even when the
> transmitter (PTT) isn't active. This reduces the impact of the variable
> start-up latency issues which simpleusb has classically exhibited.


fob startup - was: DAHDI timing and ASL

Ken KE2N
 

My experience is with the usbradio channel. Not sure if it will happen with simple usb.

The "fix" could be a hack as you say.  Although, if the hardware requires it ... then you might say it's a feature ;-)

To me it seems like some pipeline underflows, or overflows, right at the start.  My observation is that it happens when ASL tries to key up the radio and talk ... essentially at the same time.  It does not happen *every* time.  But I heard the effect three times in a short while after starting the repeater up last night.  And I think I heard one chopped up CW ID today sometime. Once the audio gets going, it's fine.

People whose radios are slow to open the squelch will never have heard this.  They will also never have heard the first letter of the repeater ID on a cold key-up (and probably don't care anyway).

Doing a Google search I am reminded that this fix was for simple usb (I do not know if it is applicable to usbradio - as you know, that driver is not favored in the other flavor of asterisk controller).

Re-reading the text below (which google just found for me), this fix was actually intended for another problem. Although it might also fix the issue I am talking about.

... the simpleusb driver continues
> to send frames of silence to the audio adapter at all times; even when the
> transmitter (PTT) isn't active. This reduces the impact of the variable
> start-up latency issues which simpleusb has classically exhibited.


Re: DAHDI timing and ASL

Steve N4IRS
 

Ken,
Not sure what you mean by running the data stream continuously. I'm thinking a startup delay may help, but both seem like a hack rather then a fix. What channel driver are you seeing this with?

Steve N4IRS

On 12/30/19 1:43 PM, Ken KE2N via Groups.Io wrote:
This (dahdi_dummy) worked well with my RPI3 and it even helped results on a big hulking quad core machine, by raising the occasional worst-case result..

The remaining problem that I see with ASL1.01 is - for lack of a better name - usb fob startup.  When the repeater has been quiet and decides to spit out a morse or voice ID, sometimes the first morse character or the first syllable or two of the voice comes out choppy. 

In the other camp I believe they fixed this problem by running the data stream continuously, is that hard to do?

Ken


Re: DAHDI timing and ASL

Ken KE2N
 

This (dahdi_dummy) worked well with my RPI3 and it even helped results on a big hulking quad core machine, by raising the occasional worst-case result..

The remaining problem that I see with ASL1.01 is - for lack of a better name - usb fob startup.  When the repeater has been quiet and decides to spit out a morse or voice ID, sometimes the first morse character or the first syllable or two of the voice comes out choppy. 

In the other camp I believe they fixed this problem by running the data stream continuously, is that hard to do?

Ken


Re: DAHDI timing and ASL

Andrew Koenig
 

Steve,

This really seemed to do the trick with the dahdi_test results. I'm really looking forward to audio reports from users.

Any idea on why that line was commented out?

I'll be sure to pass the thanks along to Bryan as well.

73 de KE5GDB

====================

From an RPi 2B+ w/ ASL 1.01:

root@43776-BridgePi:~# dahdi_test -c 100
Opened pseudo dahdi interface, measuring accuracy...
99.618% 99.565% 99.620% 99.631% 98.447% 99.601% 99.602% 99.603%
99.601% 98.445% 99.598% 99.601% 99.585% 99.617% 98.436% 99.593%
99.601% 99.601% 99.597% 98.441% 99.603% 99.601% 99.572% 99.630%
98.445% 99.600% 99.609% 99.594% 99.592% 98.480% 99.601% 99.647%
99.601% 99.600% 98.445% 99.602% 99.602% 99.573% 99.629% 98.486%
99.600% 99.595% 99.650% 99.601% 98.491% 99.601% 99.599% 99.648%
99.605% 98.508% 99.612% 99.600% 99.648% 99.602% 98.489% 99.583%
99.636% 99.621% 99.607% 98.450% 99.610% 99.593% 99.605% 99.602%
98.444% 99.545% 99.653% 99.600% 99.605% 98.447% 99.592% 99.600%
99.606% 99.600% 98.442% 99.593% 99.605% 99.598% 99.610% 98.456%
99.537% 99.626% 99.639% 99.611% 98.450% 99.601% 99.602% 99.601%
99.603% 98.447% 99.602% 99.601% 99.602% 99.613% 98.450% 99.597%
99.601% 99.600%
--- Results after 98 passes ---
Best: 99.653% -- Worst: 98.436% -- Average: 99.382118%
Cumulative Accuracy (not per pass): 99.980
root@43776-BridgePi:~# modprobe dahdi_dummy
root@43776-BridgePi:~# dahdi_test -c 100
Opened pseudo dahdi interface, measuring accuracy...
99.986% 99.981% 99.991% 99.992% 99.991% 99.992% 99.992% 99.992%
99.993% 99.988% 99.992% 99.992% 99.992% 99.993% 99.991% 99.991%
99.991% 99.991% 99.992% 99.990% 99.992% 99.992% 99.991% 99.993%
99.991% 99.991% 99.991% 99.992% 99.992% 99.991% 99.992% 99.992%
99.991% 99.991% 99.991% 99.992% 99.991% 99.992% 99.992% 99.991%
99.992% 99.991% 99.992% 99.992% 99.991% 99.992% 99.992% 99.992%
99.992% 99.990% 99.992% 99.992% 99.992% 99.993% 99.991% 99.992%
99.992% 99.991% 99.992% 99.992% 99.992% 99.992% 99.992% 99.991%
99.992% 99.991% 99.992% 99.992% 99.991% 99.992% 99.992% 99.992%
99.992% 99.991% 99.991% 99.992% 99.992% 99.992% 99.992% 99.991%
99.992% 99.991% 99.992% 99.992% 99.991% 99.992% 99.992% 99.992%
99.992% 99.991% 99.991% 99.990% 99.991% 99.992% 99.992% 99.992%
99.992% 99.991%
--- Results after 98 passes ---
Best: 99.993% -- Worst: 99.981% -- Average: 99.991408%
Cumulative Accuracy (not per pass): 99.991
root@43776-BridgePi:~#

RPi 2B+ w/ DIAL:

root@Rosston220:~# dahdi_test -c 100
Opened pseudo dahdi interface, measuring accuracy...
99.999% 99.989% 99.991% 99.980% 99.995% 99.994% 99.996% 99.995%
99.999% 99.986% 99.989% 99.985% 99.993% 99.995% 99.996% 99.995%
99.996% 99.993% 99.997% 99.992% 99.994% 99.981% 99.992% 99.993%
99.997% 99.616% 99.996% 99.615% 99.986% 99.993% 99.626% 99.613%
99.987% 99.992% 99.628% 99.613% 99.997% 99.990% 99.980% 99.997%
99.995% 99.993% 99.993% 99.995% 99.995% 99.995% 99.986% 99.993%
99.992% 99.993% 99.987% 99.625% 99.601% 99.993% 99.995% 99.995%
99.993% 99.985% 99.983% 99.615% 99.600% 99.995% 99.993% 99.615%
99.602% 99.612% 99.991% 99.602% 99.613% 99.603% 99.997% 99.992%
99.994% 99.613% 99.602% 99.612% 99.601% 99.996% 99.996% 99.990%
99.992% 99.981% 99.994% 99.994% 99.996% 99.993% 99.994% 99.999%
99.999% 99.991% 99.988% 99.990% 99.993% 99.989% 99.990% 99.986%
99.993% 99.994%
--- Results after 98 passes ---
Best: 99.999% -- Worst: 99.600% -- Average: 99.914483%
Cummulative Accuracy (not per pass): 99.993
root@Rosston220:~# modprobe dahdi_dummy
root@Rosston220:~# dahdi_test -c 100
Opened pseudo dahdi interface, measuring accuracy...
99.990% 99.979% 99.980% 99.992% 99.991% 99.988% 99.994% 99.995%
99.995% 99.994% 99.994% 99.995% 99.994% 99.996% 99.993% 99.995%
99.995% 99.996% 99.995% 99.988% 99.988% 99.995% 99.994% 99.996%
99.993% 99.994% 99.995% 99.995% 99.996% 99.994% 99.995% 99.995%
99.995% 99.995% 99.993% 99.994% 99.995% 99.998% 99.992% 99.991%
99.988% 99.994% 99.995% 99.996% 99.993% 99.995% 99.995% 99.997%
99.994% 99.987% 99.987% 99.995% 99.994% 99.996% 99.993% 99.994%
99.994% 99.994% 99.997% 99.987% 99.991% 99.991% 99.989% 99.996%
99.993% 99.994% 99.994% 99.995% 99.995% 99.994% 99.995% 99.995%
99.995% 99.995% 99.995% 99.995% 99.995% 99.994% 99.995% 99.995%
99.995% 99.995% 99.995% 99.995% 99.995% 99.995% 99.995% 99.995%
99.995% 99.994% 99.994% 99.994% 99.994% 99.996% 99.993% 99.997%
99.991% 99.990%
--- Results after 98 passes ---
Best: 99.998% -- Worst: 99.979% -- Average: 99.993478%
Cummulative Accuracy (not per pass): 99.994
root@Rosston220:~#


Re: Allison Ducking

Adam KC1KCC
 

Looks like we missed ducking for local rx.  It’s currently only ducking for remote.  I’ll submit a pull request later on this evening.

Adam KC1KCC


Allison Ducking

Steve N4IRS
 
Edited

Just a quick note for now.
Adam KC1KCC and Mike N4IRR have ported the Allison ducking code from Steve W9SH to the DVSwitch fork of ASL. We are still testing but we know that you can now reduce or increase the level of Allison sent to a connected radio, USRP (Analog_Bridge) or DVSM. We are still testing the actual reduction of Allison level if there is a inbound signal. This should be considered a work in progress.
Add these settings to the node stanza of rpt.conf:

telemnomdb = -10
telemduckdb = -10
 
;down = -30
;up = 10
;normal = 0
 


Steve N4IRS


Text messaging support added to chan_usrp

Steve N4IRS
 

Mike has added text messaging support to chan_usrp and app_rpt. The text messages are used by DVSM and it's also nice to be able to send a pop up message to the client.
I have checked in the change to the DVSwitch Asterisk repo.

101 - 120 of 126