Ok need some guidance or best practice advise on this setup. I have everything seemingly working but echolink is not the best quality - garbled. However, all other audios sound great. Then troubleshooting folks years ago said running it on the same device is bad. But its not 2020 or before.
I am running the new allstar3-arm64-3.0.12 image on a raspberry pi 3B+ but just now put the card in a Pi4 to see if it performs better.
I am running this as a repeater extension from the limited repeater site. Allstar with AIOC dongle and 5W radio. With this setup I have SkywarnPlus, Broadcastify, Echolink WR4VR-R, and our announcements, and hourly time.
Seemed to work well except this morning the echolink audio coming in on echolink was garbled, going out over RF and to the repeater was perfect. All outher audio sounded great from asl link etc.
Guess my question is should I be running the Echolink WR4VR-R on this or set up a cloud Allstar with Echolink using WR4VR-L and link to the echolink server. The reason I want to go with the all in one is to remove this windows Echolink system to the all in one.
Or run the WR4VR-R in the cloud and WR4VR-L local and connect the allstar nodes cloud and local linked?
Is there any club that has a presentation that is more current on configuration in this way?
On the surface, this sounds like a network bandwidth issue to the EL servers.
Perhaps change the servers you are pointing to.
Or one of them may be having an issue temporarily.
There are no general issues with ‘all in one’ till you hit a limit with the number of steams and your memory and cpu bandwidth. And that depends on how much xtra stuff is running.
But I have to ask, if it was playing fine on the RF and repeater, just what were you listening on that was garbled ? you did not quite nail that one and it is a hard thing to guess.
I think it may have been an echolink server issue. However, I think that since I did spin this cloud server up I may go this route and host Echolink WR4VR-R on the cloud server and link that node with my local node. That way I can use echolink locally on my home network without messing with UDP issues.
This will also allow me to keep the local node private and everyone can link to the cloud one that is perm linked to the local ASL that is on RF to the repeater. This makes sense to me.
Anyone have any suggested configs for the tones, telem, ID,s etc that seems to work? The repeater has its own ID, no tone but a sq tail. Dont need it bouncing back non stop. Also dont want connection announcements that would be annoying during peak and net times everyone connecting and disconnecting. I think I have those turned off.
Tom, your best bet for you echolink server is to probably use TheLinkBox software to host the echolink in the cloud, and use the chan_tlb module in Allstar to connect the EL and Allstar servers together. I’ve been doing this for years and having great success with it.
When I last tried to use TLB a couple of years ago on ASL2, I ran into some weird issues. For example, EchoLink users wouldn’t be heard until a couple of cycles from Allstarlink nodes if the nodes were idle for a while. Still better than the “under water” problem hosting multiple connections from chan_echolink, where each successive connection would get progressively worse and worse audio back from the nodes, but upstream from them was fine.
So. I hope both of these problems have been addressed in ASL3.
I’m currently using HamVoIP to bridge a -r node to a conference server, because it’s more stable than anything else I’ve tried, and gives far better control than chan_echolink, but would love to get away from that setup eventually in favor of TLB if it actually works the way it should.
Honestly, I’d love to not support EchoLink at all, but we can’t always get what we want.
I been experimenting with it for days. two devices and new configs. I think I have good audio with a different radio but now have a bounce between allstar and the repeater, will reengage this weekend with this project.