开云体育

I have a situation that is generating a lot of duplicate packets.



Station A sends a message to Station B, via Station C.



But if Station B receives the message direct and ACK's, then receives the
same message via C, it ACK's again, therefore generating a duplicate ACK
which is repeated by C (as expected, as it came via the digi).



So instead of three packets, I get five.



Is there any way of configuring UI-View to supress the duplicate ACK, or at
least adjusting a timer so it won't ACK again within xx seconds?







Jim

Jim G1HUL wrote...

Station A sends a message to Station B, via Station
C. Is there any way of configuring UI-View to
suppress the duplicate ACK, or at least adjusting
a timer so it won't ACK again within xx seconds?

Nope. Station A is sending the message because it
didn't receive an ACK. If A keeps sending it to
station B, B will keep sending an ACK each time
it receives it.

Assuming station B is using UI-View, it will either
use a reverse path derived from the incoming message,
or it will use the default path from the station setup
if enabled. That is under options in the message window.

Station A could adjust the path, or station B could
consider what path it is using in the station setup
and decide whether it would be better.

If station A is using UI-View, it could decide the
retry interval, how many times to try sending a message,
whether to "retry on heard" and whether to expire
un-ACKed messages. It doesn't get much better.

Station C could up the power or improve it's antenna - hi!

--
73 Keith VE7GDH
"I may be lost, but I know exactly where I am!"

Nope. Station A is sending the message because it didn't receive an ACK

In this case, wrong. Retry is set for 5 seconds, this is all happening within 2-3 seconds.

A (the source) is an OpenTracker T3
B (the destination) is using UI-View
C (the digi) is a KPC-3+ (running v9.1)

A only ever sends the message once and is receiving the ACK from B before the repeated beacon via C is even transmitted.

The repeated beacon is then treated as a new message by B and ACK'd as well.

Sequence is as follows:
A > B & C (Message)
B > A (ACK, sent direct)
C > B (Digi'd message)
B > C (ACK, sent via digi)
C > A (Digi'd ACK)

Accepted that UI-View doesn't know that the ACK was received and this is how the APRS protocol intends it to work, however I'm looking at whether I can tweak it to make assumptions based on these specific conditions.

(This is all set up on my bench, so all stations can hear each other).



Jim

-----Original Message-----
From: ui-view@... [mailto:ui-view@...]
Sent: 12 March 2017 22:29
To: ui-view@...
Subject: Re: [UI-View] Supressing multiple message ACK's

Jim G1HUL wrote...

> Station A sends a message to Station B, via Station > C. Is there any way of configuring UI-View to > suppress the duplicate ACK, or at least adjusting > a timer so it won't ACK again within xx seconds?

Nope. Station A is sending the message because it didn't receive an ACK. If A keeps sending it to station B, B will keep sending an ACK each time it receives it.

Assuming station B is using UI-View, it will either use a reverse path derived from the incoming message, or it will use the default path from the station setup if enabled. That is under options in the message window.

Station A could adjust the path, or station B could consider what path it is using in the station setup and decide whether it would be better.

If station A is using UI-View, it could decide the retry interval, how many times to try sending a message, whether to "retry on heard" and whether to expire un-ACKed messages. It doesn't get much better.

Station C could up the power or improve it's antenna - hi!

--
73 Keith VE7GDH
"I may be lost, but I know exactly where I am!"


------------------------------------
Posted by: Keith VE7GDH <ve7gdh@...>
------------------------------------

Please do not top post, and trim quoted text as much as possible.

UI-View website:

UI-View Registration:
Select language & fill in your name and call sign. Return later to collect your registration.

APRS Server List: To update the APRS Server List, change the download URL to... aprs2.net/APRServe2.txt

For North American users, PMap 9 (Precision Mapping 9.0) along with PMapServer 9 can provide street level mapping for all of North America. They can be installed without hassle on Windows 7 & 8. PMapServer is available for download on the UI-View website. However, Undertow Software is no longer selling new copies of PMap 9, but existing owners can continue to use it as long as they can get it registered.

Users of anything newer than Windows XP should not install UI-View below Program Files. Instead, create a folder elsewhere. To view UI-View's built-in context sensitive help file, download and install WinHlp32.exe.


Stephen WA8LMF has many useful hints and tips about setting up and using UI-View on website:
------------------------------------

Yahoo Groups Links

Jim G1HUL wrote...

In this case, wrong. Retry is set for 5 seconds, this is all happening within 2-3 seconds.

But you said below the source of the message was a T3, so UI-View's message retry interval doesn't come into it. The setting I mentioned would only affect messages originated by the UI-View station.

A (the source) is an OpenTracker T3
B (the destination) is using UI-View
C (the digi) is a KPC-3+ (running v9.1)

A only ever sends the message once and is receiving the ACK from B before the repeated beacon via C is even transmitted.

The repeated beacon is then treated as a new message by B and ACK'd as well.

It should not be treated as a new message. Is there not a unique message number at the end? You can verify this by watching UI-View's terminal window.

Sequence is as follows:
A > B & C (Message)
B > A (ACK, sent direct)
C > B (Digi'd message)
B > C (ACK, sent via digi)
C > A (Digi'd ACK)

If all is as above, there is no extra ACK. A (the T3) sends the message. B (UI-View) hears it and sends an ACK. Then C (KPC-3+ digi) digipeats the original message. B hears it again and sends another ACK.

If all is above, I don't see an an extra ACK.

How do you know if A received the original ACK from B? Mind you, I don't think it would care if it received both the original direct ACK from B plus one a fraction if a second later via the digi C.

I just don't see an extra ACK if all is as you outlined. C perhaps just held off digipeating the message because it heard B already transmitting the ACK. Does the digi have DWAIT set to 0? Of course, PERSIST and SLOTTIME come into it too.

Accepted that UI-View doesn't know that the ACK was received and this is how the APRS protocol intends it to work, however I'm looking at whether I can tweak it to make assumptions based on these specific conditions.

(This is all set up on my bench, so all stations can hear each other).

That helps.

I was going to ask if A hears the ACK direct from B, but if A only sends the message once, it must have received an ACK… either direct or later via the digi.

Can you see on the T3 if it hears both the original ACK and the digi' done? I mean does it actually decode both of them, not just if A's radio heard them.

I assume this is going to be deployed somewhere that B won't be able to hear A direct. Try putting a dummy load on B and move A far enough away that B can't hear it direct. Watch UI-View's terminal window.

It will of course help if someone is available to originate the message from The T3.

--
73 Keith VE7GDH
"I may be lost, but I know exactly where I am!"

Sequence is as follows:
A > B & C (Message)
B > A (ACK, sent direct)
C > B (Digi'd message)
B > C (ACK, sent via digi)
C > A (Digi'd ACK)

If all is as above, there is no extra ACK. A (the T3) sends the message. B (UI-View) hears it and sends an ACK. Then C (KPC-3+ digi) digipeats the original message. >B hears it again and sends another ACK.

If all is above, I don't see an an extra ACK.

I think the extra ack that Jim is on about is the ack of the digi'd message; since B has already ack'ed the message which was received direct.

I think he is querying why an ack is also sent for the same message that is received via the digi after the ack to the direct version of the same message has been sent.

73
Jeff G8HUL

In this case, wrong. Retry is set for 5 seconds, this is all happening within 2-3 seconds.

But you said below the source of the message was a T3, so UI-View's message retry interval doesn't come into it. The setting I mentioned would only affect messages originated by the UI-View station.

I also did not say the retry was UI-View. It's not, it's the T3 retry I was talking about here. I know UI-View's retry has nothing to do with it.


Bob has indicated this is how it's supposed to work, I'm happy with that explanation and need to look at other ways at reducing the traffic.



Jim

Correct :-)

I'll post monitor logs tomorrow to show exactly what's happening.



Jim
________________________________________
From: ui-view@... [ui-view@...]
Sent: 13 March 2017 12:25
To: ui-view@...
Subject: RE: [UI-View] Supressing multiple message ACK's

Sequence is as follows:
A > B & C (Message)
B > A (ACK, sent direct)
C > B (Digi'd message)
B > C (ACK, sent via digi)
C > A (Digi'd ACK)

If all is as above, there is no extra ACK. A (the T3) sends the message. B (UI-View) hears it and sends an ACK. Then C (KPC-3+ digi) digipeats the original message. >B hears it again and sends another ACK.

If all is above, I don't see an an extra ACK.

I think the extra ack that Jim is on about is the ack of the digi'd message; since B has already ack'ed the message which was received direct.

I think he is querying why an ack is also sent for the same message that is received via the digi after the ack to the direct version of the same message has been sent.

73
Jeff G8HUL




------------------------------------
Posted by: jeff 1 <g8hul@...>
------------------------------------

Please do not top post, and trim quoted text as much as possible.

UI-View website:

UI-View Registration:
Select language & fill in your name and call sign. Return later to collect your registration.

APRS Server List: To update the APRS Server List, change the download URL to... aprs2.net/APRServe2.txt

For North American users, PMap 9 (Precision Mapping 9.0) along with PMapServer 9 can provide street level mapping for all of North America. They can be installed without hassle on Windows 7 & 8. PMapServer is available for download on the UI-View website. However, Undertow Software is no longer selling new copies of PMap 9, but existing owners can continue to use it as long as they can get it registered.

Users of anything newer than Windows XP should not install UI-View below Program Files. Instead, create a folder elsewhere. To view UI-View's built-in context sensitive help file, download and install WinHlp32.exe.


Stephen WA8LMF has many useful hints and tips about setting up and using UI-View on website:
------------------------------------

Yahoo Groups Links