1. Topics
  2. M17 to ASL

M17 to ASL

Skyler Fennell
 

Is there a solution to bridge M17 to ASL?
Steve N4IRS
 
Edited

No We will cross that bridge when we come to it.


On 11/15/20 11:01 AM, Skyler Fennell wrote:
Is there a solution to bridge M17 to ASL?
Skyler Fennell
 

Copy,

The mode kinda sucks anyway, I love the codec being open source but it sounds like garbage, my ears have to strain to understand some people depending on if their voice fits the codecs ideals. 

We need a mode that runs 8-10kbps over ham radio, the bands are wide open, there's no traffic and we have plenty of bandwidth on UHF for example. We're not commercial, and not running out of space. 

Sure, we might be running out of repeater coordinations in large cities but just because we have full coordinations, does not mean people are using them...

I would love to see an implementation of G.729 or similar directly over RF. 


On Sun, Nov 15, 2020 at 9:08 AM Steve N4IRS <szingman@...> wrote:
No

On 11/15/20 11:01 AM, Skyler Fennell wrote:
Is there a solution to bridge M17 to ASL?
Steve KC1AWV
 

Skyler,

I'm sorry that your experience with M17 hasn't been as stellar as some may expect. Please, understand that the protocol is still very much in its infancy, and there are many people working on the protocol to improve it.

As of now, there are no plans by the M17 Working Group on implementing any sort of cross-mode / cross-protocol capability, as the protocol is still not finished. There are several projects working on doing so, but again these are all very much in an 'alpha' stage. If you would like to participate or know more about the progress, you may visit the website or join us on our chat channels to further the discussion there.

Thanks!

Steve KC1AWV
Skyler Fennell
 

Thank you Steve, I really appreciate your work! 



On Mon, Nov 16, 2020 at 6:31 AM Steve KC1AWV <smiller+groups@...> wrote:
Skyler,

I'm sorry that your experience with M17 hasn't been as stellar as some may expect. Please, understand that the protocol is still very much in its infancy, and there are many people working on the protocol to improve it.

As of now, there are no plans by the M17 Working Group on implementing any sort of cross-mode / cross-protocol capability, as the protocol is still not finished. There are several projects working on doing so, but again these are all very much in an 'alpha' stage. If you would like to participate or know more about the progress, you may visit the website or join us on our chat channels to further the discussion there.

Thanks!

Steve KC1AWV

Skyler Fennell
 

Sorry Steve (kc1awv) for bad mouthing the mode, sometimes I forget the filter, and think its a really cool project and am willing to help where I can to improve on it.

I’m guilty of it too but a lot of us take all this free open source software for granted.

Skyler 

On Mon, Nov 16, 2020 at 7:09 AM Steve N4IRS <szingman@...> wrote:

[Edited Message Follows]

No We will cross that bridge when we come to it.

On 11/15/20 11:01 AM, Skyler Fennell wrote:
Is there a solution to bridge M17 to ASL?
Steve KC1AWV
 

As of now, there is only one known path to get M17 to ASL, and that is to use M172DMR.

nostar MMDVM_CM fork: https://github.com/nostar/MMDVM_CM

Using M172DMR, you can cross-mode M17 to a DMR talkgroup. Then it's a simple matter of getting that DMR TG to ASL.

If anyone's interested in creating an ASL to M17 bridge, feel free to reach out to me.

Steve KC1AWV
Tony Langdon
 

Hmm, I'd have thought it better to have Analog_Bridge or an equivalent program to transcode between M17 (Codec2) and PCM.  Doing it via DMR means there's an unnecessary transcoding step, when going from M17 to ASL (i.e. going via AMBE+2), degrading audio quality unnecessarily.  I've built my multimode gateway on the principle of transcoding as few times as possible.  From any digital mode to PCM is only one transcoding operation, between any 2 modes, there is never more than 2 transcoding operations (one source to PCM, then one from PCM to the target codec).  And the release of Analog_Reflector has allowed me to (mostly) preserve metadata across modes.
`

On 12/3/21 8:46 am, Steve KC1AWV wrote:
As of now, there is only one known path to get M17 to ASL, and that is to use M172DMR.

nostar MMDVM_CM fork: https://github.com/nostar/MMDVM_CM

Using M172DMR, you can cross-mode M17 to a DMR talkgroup. Then it's a simple matter of getting that DMR TG to ASL.

If anyone's interested in creating an ASL to M17 bridge, feel free to reach out to me.

Steve KC1AWV 


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

Perhaps this would require adding Codec2 support and an M17 mode to Analog_Bridge similar to use md380-emu.
The Codec2 server version is available

https://github.com/ea3ihi/codec2

and it can be used in a similar way as md380-emu via UDP port
SP2ONG Waldek
 

The Codec2 server is used in DMRStation project:

https://github.com/ea3ihi/DMRStation/blob/master/DMRStation.ini

# md380-emu
[ambe]
ambeServerHost=127.0.0.1
ambeServerPort=2460
 

#Codec2 server

[codec2]
codec2ServerHost=127.0.0.1
codec2ServerPort=2470
enabled=0
 

So it looks like similar in Analog_Bridge
Tony Langdon
 

This sounds like a really good way to do it.

On 12/3/21 6:10 pm, SP2ONG Waldek wrote:
Perhaps this would require adding Codec2 support and an M17 mode to Analog_Bridge similar to use md380-emu.
The Codec2 server version is available

https://github.com/ea3ihi/codec2

and it can be used in a similar way as md380-emu via UDP port 


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

Yep, that sounds reasonable.  The Codec2 server already exists, might as well make use of what's already out there.

On 12/3/21 6:14 pm, SP2ONG Waldek wrote:
The Codec2 server is used in DMRStation project:

https://github.com/ea3ihi/DMRStation/blob/master/DMRStation.ini

# md380-emu
[ambe]
ambeServerHost=127.0.0.1
ambeServerPort=2460
 

#Codec2 server

[codec2]
codec2ServerHost=127.0.0.1
codec2ServerPort=2470
enabled=0
 

So it looks like similar in Analog_Bridge


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

Tony, my thoughts exactly. A path between two points should be made as simple as possible.

I was unaware of the Codec2 server. This should make things a whole lot easier. M17Gateway exists as a 'beta', in the sense that it's not completely tested.

https://github.com/g4klx/M17Gateway

I think we have the parts, we just need a plan to put them together.

Steve KC1AWV
Tony Langdon
 

On 13/3/21 1:34 am, Steve KC1AWV wrote:
Tony, my thoughts exactly. A path between two points should be made as
simple as possible.
Yes, I have a principle of doing as little as possible with the audio,
and that principle goes back to the early days of EchoIRLP (way back in
2002-2003), where I theorised that it should be possible to pass traffic
from Echolink to IRLP without decompressing the audio, which others were
able to implement in code.  This became a feature of EchoIRLP and the
shared IRLP/Echolink conferences in use today.

I was unaware of the Codec2 server. This should make things a whole
lot easier. M17Gateway exists as a 'beta', in the sense that it's not
completely tested.
Yep, why reinvent the wheel, when all you need to do is bolt an existing
wheel onto your new axle? :)

https://github.com/g4klx/M17Gateway

I think we have the parts, we just need a plan to put them together.
I have a feeling you're right.

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

Ok, so the only issue I see at this point is with Analog_Bridge. It's not aware of M17 as a digital mode and does not know how to send frames to M17Gateway.

I suppose we'll have to wait until Analog_Bridge supports M17.

Steve KC1AWV
1 - 15 of 15