At the beginning of November, Rob G4ZWH set up a bridge on the FreeSTAR to link with a Zello channel. This proved to be rather popular and generated a lot of activity on the network.
We got chatting and it transpired that the bridge was a bit of a hodge-podge of a Windows Zello client, a SIP Softphone, with DTMF signalling to operate the PTT and get everything working together. We found that there is a great Zello API that lets consumers build their own PTT apps. A few evenings of furious coding got us to a point where we had a working bridge written in Python that could run on a low cost Linux VPS instead of a Windows Desktop.
The latest version of the bridge can be found at github://mattmelling/asl-zello-bridge.
The FreeSTAR network admin team are incredibly supportive of experimentation, and after extensive testing we swapped over from the V1 bridge to the V2 bridge earlier this week. We've since seen CumbriaCQ start using the bridge and Lee M0LLC has been a great help ironing out some bugs of the type that only pop out when you throw real users at something.
How it works
Zello provides a Websocket-based Channels API which can be used with most of their PTT products, including Zello Consumer, the free version. The bridge connects and authenticates with the Channels API and streams audio from it to an Allstar node with a USRP (chan_usrp.so) interface.
Transcoding is done with libopus via the PyOgg library, which presented some difficulties because the latest version pulled down from Pypi doesn't seem to be compatible with the latest libopus release.
Teething issues
While rolling out the bridge we did have a few challenges.
Channel name case sensitivity
Channel names in Zello aren't case sensitive, except for when they are. Specifically, the Channels API will let you authenticate with a channel name in a different case (e.g. we were initially using "freestar" for the channel "FreeSTAR"), and even let you send audio in. However, you will not receive audio back from Zello if the case does not match. It appears that someone has used a case-sensitive comparison in the audio routing part of the back end. There is more information in this GitHub ticket (#236) as well as #233. Zello seem to be aware, so maybe this will be fixed in the future.
Zello Work audio issues
One of our users has some bridges to 'Other Networks', which uses Zello Work - private Zello server. We observed that the audio out of Zello Work in to the bridge could be very stuttery and not all that readable. We believe it is down to codec settings for Zello Work, although the exact cause is not known at the moment. Experimentation with various codec settings continues.
Deauth and long overs
We also saw that occasionally the channels API would boot the bridge user off the channel. The bridge would then restart and try to log in again, however if it was in the middle of a QSO and incoming data from USRP would interrupt the authentication process, and cause it to log out again. The fix was simple - a variable to track auth state and a change to reject any incoming data from the network until we are authenticated - but it took a lot of reading logs and monitoring the network to work it out. If nothing else this highlights the importance of a proper 3 second gap between overs!
Replay
One of the things that has been reported a few times is extreme latency, or delayed conversations - up to 5 minutes behind the analog side of the network! Rather than being caused by the bridge, this is actually caused by the Zello app's replay functionality that will record and play back messages if a transmission is stopped due to a phone call, change of availability status (e.g. moving yourself to Busy), or media event on the device running the Zello app. Sadly it doesn't appear possible to completely disable this at the channel level - something that is available in the Zello Work product. Our strategy right now is to approach this as a training issue, and we are planning to put in place some information for users of the bridge, and point new users towards it.
In conclusion...
This project has not been without its challenges. Feedback from users so far has been fantastic, and I'm really excited to see other network exploring Zello integration alongside FreeSTAR. Network radio might not be everybody's cup of tea, however I see it as an incredibly useful tool that can be called upon to maintain communication, when RF over the amateur bands isn't possible.