[SkyHub] 5 secs between transmissions

Sat Apr 10 17:09:25 EDT 2021

Agreed, thanks Skyler! It'd be nice to have this "theory of operation" on
https://skyhublink.com/ .

I've seen a lot of latency issues in digital audio since it is generally
processed in chunks and processing does not start until the full chunk is
available. I think, though, that once the input buffer for the first
buffer has been filled, additional delay should be limited to processing
time of each subsequent operation (those operations do not have to wait
for audio coming in real time, they just immediately process the chunk
passed to them). But, if there is delay (such as transmission over the
Internet), that gets added. On Internet transmission, it's a balancing act
between packet size (smaller has less latency) and bandwidth (smaller
packets take more bandwidth since each packet still needs full headers).

In any case, what you've set up is VERY IMPRESSIVE!

Thanks!

Harold

> Thanks Skyler,
>
> Great reminder of the complexity and hoops that are jumped through just so
> we can key up and have magic happen.
> And thanks for all you folks do to keep the whole package running.
> â€˜Preciate ya!!!
>
> Steve K.
>
> On Apr 10, 2021, at 2:24 PM, Skyler F <electricity440 at gmail.com> wrote:
>
> ï»¿
> On Sat, Apr 10, 2021 at 1:27 PM Harold Hallikainen
> <harold at mai.hallikainen.org> wrote:
>> Where are the delays being introduced in the system? Why is digital
>> slower
>> than analog?
>
> Harold,
>
> There are many issues with the SkyHub on delays and link issues. Some of
> which we can control, and some of which we have no control over. Out of
> the things we can control, I can hope we figure out a solution. Here are a
> list of problems.
>
> 1. 449.450.
> This repeater is probably the toughest repeater to use on the SkyHub and
> is in DIRE NEED of being fixed. It is linked in to the hub via a node
> radio on it's frequency. The repeater has courtesy tones and CW ID that we
> don't want to hear through the network, so how do we filter that out? The
> way we filter it out by having the repeater ONLY send its 127.3 TX CTCSS
> code when a user has keyed up the repeater. All other traffic such as hang
> times, CW ID, announcements, and courtesy tones are theoretically supposed
> to have NO TX CTCSS on the repeater.
>
> Unfortunately, the repeaters controller has a glitch in it, and it takes
> anywhere between 0.5 and 5 seconds to begin transmitting TX CTCSS tone.
> This causes users to be cut off on the rest of the system and not be heard
> unless they hold the PTT trigger forever. We are trying to find a solution
> to get internet at the site and link AllStar directly into the controller
> to get the system both on full duplex, and eliminate the controller
> issues. Trying to work with RMHAM has been tough because although they
> have IP up there, they don't provide public internet, and we don't have
> any other endpoints with public internet.
>
>
> 2. Digital Delays on the hub.
> The hub takes maybe 0.5 to 1 second to do the analog to digital
> conversion. We are running many software packages on the physical hub
> computer, and it just has to run through all of them. This is what has to
> happen when someone keys up on analog and comes out digital. The route a
> packet would have to do if someone comes in on Analog and out on a fusion
> hotspot is as follows:
>
> Analog Repeater ---> AllStar Link node --> Internet --> SkyHub AllStar
> 46079 --> Analog_Bridge --> MMDVM_bridge --> HBLink  --> MMDVM_Bridge_Ysf
> ---> YSF_Reflector --> Internet ---> Fusion Hotspot.
>
> A second or so delay for this is honestly not too bad, and just is what it
> is.
>
> 3. Digital Delays on the Wires-X Network.
>
> Unfortunately, to use the Wires-X network, we cannot host our own server.
> This is held by Yaesu on their end, and we have no control of it. This is
> actually where most of our delays come from. We have to run a physical RF
> link to convert the open source YSF_Reflector to the WIRES-X network. Once
> audio comes onto the fusion servers, it takes a variable 1 second to 6
> seconds for the audio to come back out. So someone on 449.625 for example
> may be 6 seconds ahead of someone on 448.350. We have no control of the
> WIRES-X network, and this is all on Yaesu, I don't know why the delays are
> so awful on their network.
>
> 4. PTT Release
>
> This is the weirdest glitch because it really should not happen, but for
> some reason, I believe in the Analog_Bridge software, if you unkey right
> after you are done talking without waiting a 1/2 second, the audio will
> get cut off. For some reason the end-of-transmission signal cuts the audio
> out before the software is finished processing the audio and doing the
> analog to digital conversion. I hope they fix this on a software update.
>
> 5. HALF-DUPLEX.
>
> AllStar Link has a huge advantage of being full-duplex. Many of our analog
> repeaters allow users to talk while other users are talking, and it will
> mix the audio of the remote station. That way if two stations are talking
> on two different links, you can actually hear both people at the same time
> and tell that they are doubling! Unfortunately, with digital, we lose all
> of this.
>
> If two people talk at the same time, it is basically whoever keyed up
> first. If they both are pretty similar on who keyed up first, the packets
> of the station who was slightly behind will be completely dropped and the
> other station will not know. To make this even more challenging, if the
> stations are on two opposite ends, such as on Wires-X and the servers are
> being a bit laggy and have a 6 second delay, you won't even know the other
> person has started talking until 6 seconds after they have, and that could
> completely clobber you!
>
> Summary:
> The delays are there, and they stink, but we have a few things to maybe
> help this a little. First is fixing 449.450, making it full duplex with
> internet at the site. Second, there is also a package called
> analog_reflector, which will be the backbone for al digital modes instead
> of using allstar as the backbone. This may help speed things up a little
> and i'm beginning to experiment with this.
>
> hope the info helped
> skyler
>
> On Sat, Apr 10, 2021 at 1:27 PM Harold Hallikainen
> <harold at mai.hallikainen.org> wrote:
>> Where are the delays being introduced in the system? Why is digital
>> slower
>> than analog?
>>
>> Harold
>>
>>
>> > If we wait 5 seconds people will think weÃ¢â‚¬â„¢re gone and start
>> talking when
>> > itÃ¢â‚¬â„¢s our turn. CanÃ¢â‚¬â„¢t have that.
>> >
>> > Over.
>> >
>> > Cris Alexander
>> >
>> > Sent from my amazing iPhone 12.
>> >
>> >> On Apr 10, 2021, at 10:58 AM, Greg Liverman <greg.liverman at live.com>
>> >> wrote:
>> >>
>> >> Ã¯Â»Â¿
>> >> This is an issue with any linked repeater system, even analog
>> repeaters
>> >> with analog links, like ColCon, CRA, CMRG, etc.
>> >>
>> >> Two operators on the same repeater will almost always beat out an
>> >> operator on a remote repeater unless they leave space between
>> >> transmissions..
>> >>
>> >>
>> >> Greg
>> >>
>> >> KÃƒËœMGL
>> >> DM78
>> >> greg.liverman at live.com
>> >> +1 719.689.0787 (office)
>> >> +1 719.330.9068 (cell)
>> >>
>> >> From: skyhub-bounces at mailman.qth.net
>> >> [mailto:skyhub-bounces at mailman.qth.net] On Behalf Of Jack Roland
>> >> Sent: Saturday, April 10, 2021 10:32
>> >> To: skyhub at mailman.qth.net
>> >> Subject: [SkyHub] 5 secs between transmissions
>> >>
>> >> One more weekend note regarding SkyHubLink!
>> >>
>> >> It is VERY IMPORTANT that we all try to remember to leave 5 seconds
>> >> between transmissions.
>> >>
>> >> Digital users are having a tough time being heard when analog
>> >> conversations are going on, just part of the nature of the beast!
>> >>
>> >> Being quick on the trigger will not allow others to be heard, and
>> while
>> >> old habits are hard to break, (and I am guilty too) we really need to
>> >> remember this as a courtesy to other operators, just good amateur
>> >> practice.
>> >>
>> >> ALSO, when in an extended QSO, which by the way are VERY WELCOME,
>> please
>> >> ask if anyone else needs to use a repeater linked in every so often.
>> >>
>> >> Thanks for your attention to these guidelines, it helps everyone
>> since
>> >> we have so many users and repeaters!  Just makes it ALL MORE FUN!
>> >>
>> >> 73Ã¢â‚¬â„¢
>> >> Jack
>> >>
>> >> Jack E. Roland, KEÃƒËœVH
>> >> www.ke0vh.com
>> >> www.skyhublink.com
>> >> Cell: 303-704-3290
>> >> HamshackHotline #12113
>> >> Wheat Ridge CO
>> >>
>> >>
>> >> ______________________________________________________________
>> >> SkyHub mailing list
>> >> Home: http://mailman.qth.net/mailman/listinfo/skyhub
>> >> Help: http://mailman.qth.net/mmfaq.htm
>> >> Post: mailto:SkyHub at mailman.qth.net
>> >>
>> >> This list hosted by: http://www.qsl.net
>> >> Please help support this email list: http://www.qsl.net/donate.html
>> > ______________________________________________________________
>> > SkyHub mailing list
>> > Home: http://mailman.qth.net/mailman/listinfo/skyhub
>> > Help: http://mailman.qth.net/mmfaq.htm
>> > Post: mailto:SkyHub at mailman.qth.net
>> >
>> > This list hosted by: http://www.qsl.net
>> > Please help support this email list: http://www.qsl.net/donate.html
>>
>>
>> --
>> FCC Rules Updated Daily at http://www.hallikainen.com
>> Not sent from an iPhone.
>> ______________________________________________________________
>> SkyHub mailing list
>> Home: http://mailman.qth.net/mailman/listinfo/skyhub
>> Help: http://mailman.qth.net/mmfaq.htm
>> Post: mailto:SkyHub at mailman.qth.net
>>
>> This list hosted by: http://www.qsl.net
>> Please help support this email list: http://www.qsl.net/donate.html
> ______________________________________________________________
> SkyHub mailing list
> Home: http://mailman.qth.net/mailman/listinfo/skyhub
> Help: http://mailman.qth.net/mmfaq.htm
> Post: mailto:SkyHub at mailman.qth.net
>
> This list hosted by: http://www.qsl.net
> Please help support this email list:
> http://www.qsl.net/donate.html______________________________________________________________
> SkyHub mailing list
> Home: http://mailman.qth.net/mailman/listinfo/skyhub
> Help: http://mailman.qth.net/mmfaq.htm
> Post: mailto:SkyHub at mailman.qth.net
>
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html

-- 
FCC Rules Updated Daily at http://www.hallikainen.com
Not sent from an iPhone.