[arm-allstar] Cut off transmissions

[Doug Crompton]

Nate,

  I truly believe it was just a coincidence that one method worked better
than the other. I really think it was a wireless vs. wired problem and it
probably required a reboot when you changed connections. A connection is
only established in two ways - *3 and *73 and disconnected with *1 and *71.
The "7" connects are permanent meaning they stay connected through network
disparities but in a poor network that does not mean it works better it
just means it will attempt to stay connected. We use *73 connects to sites
we want to stay connected to just in case there is a glitch in
connectivity. It also means if the node you are connecting to reboots or in
some way goes down the circuit will return automatically when it comes back
up.

Sometimes you can be too close to the router when using wireless. There are
also a host of other things that can cause a wireless connection to work
poorly. People don't realize that Allstar is an excellent test of a
connection because of its real-time nature. Any disparities in the network
would be heard. On the other hand if you were surfing the web with the same
disparities it would just slow the connection and in many cases, if you
were use to it, you would not give it a second thought. It makes no sense
in your case to use wireless when you are so close to a router you can run
a wire to.


On Sat, May 13, 2017 at 5:15 AM, Nathaniel Biser <kc3hoz at gmail.com> wrote:

> Doug,
>
> My apologies for cutting you off this morning, but the audio gaps in your
> transmissions were so horrible that I couldn't continue the QSO. Thanks for
> helping me fix the supermon login to asterisk manager issue I was having.
> It seems though, by fixing the login to asterisk manager issue, we
> exacerbated my transmission/audio cutoff issue.
>
> I was running my pi via wifi, I switched it over and configured it to run
> wired to my router to see if it was my wifi connection that was causing the
> transmission cutoff issue. (When the pi was wireless, it was literally
> sitting on top of my wifi router anyway, but maybe switching to wired would
> fix my issue?) it had no effect.
>
> I still have the same problem but I think I found the cause. Here's my
> step sequence:
>
> 1. On the lsnodes page, I clicked "Seatch/Command another node"
>
> 2. Typed in the remote node (27225, or whatever), selected the CONNECT
> command from the drop down menu, then I clicked submit.
>
> 3. I switch over to the Supermon page and at the bottom (where the node
> information is that indicates what node your connected to, link state,
> etc). The link state says CONNECTING, then 4 seconds later it says
> ESTABLISHED. 4 seconds later it flips back to CONNECTING, then 4 seconds
> later ESTABLISHED, then 4 seconds later, CONNECTING, etc. it does this over
> and over without end at exactly 4 second intervals .
>
> 4. I disconnected the node via the lsnodes->search/command another node
> menus; the same pages I used to connect the node in the first place.
>
> 5. On the supermon page, I enter the node number in the box at the
> top/left of the screen, and click the connect button.
>
> 6. I CONNECT AND STAY CONNECTED! Audio isn't cutting in and out
> haphazardly while monitoring or in QSO.
>
> I am not sure what the difference is between the two methods of connecting
> to a node, but obviously I'm going to use the supermon page to
> connect/disconnect for now as this seems to relieve my transmission/receive
> cutoff issue.
>
> It has been consistently connected without issue now and it appears my
> issue is resolved. I'll monitor it and report if I have the issue again.
>
> Any ideas as to why? The steps I outlined above are repeatable with the
> same results each time.
>
> -Nate
> KC3HOZ
>
>