[aprssig] PSAT & igating and Optimum antenna

[Max Harper]

Then why does the timestamp on findu match the time the beacon was received back and not the time it was actually sent. I have noticed this behavior many times over the years using various Igate software programs. I can also duplicate the problem anytime.
Back years ago when I first discovered the problem I did a test. I configured my mobile station to the same ssid as my igate and drove to a digi that was about 25 miles away. Using only a few miliwatts of power I sent some beacons that my igate couldn't hear direct, only the digi. The beacons appeared as if my igate had sent them directly to the aprs-is with no sign of the digi.
I don't know if it is an igate problem or an aprs-is problem but I see it happen all the time. I can understand it being considered a duplicate, but why does the path get changed and made to look like it was sent direct to the aprs-is when it wasn't? And the example beacon WAS sent out RF only.
Max KG4PID
       From: Steve Dimse via aprssig <aprssig at tapr.org>
 To: TAPR APRS Mailing List <aprssig at tapr.org> 
 Sent: Sunday, June 7, 2015 12:38 PM
 Subject: Re: [aprssig] PSAT & igating and Optimum antenna
   

On Jun 7, 2015, at 9:55 AM, Max Harper via aprssig <aprssig at tapr.org> wrote:

> Another problem (if you ask me) is that when you send a beacon, and that beacon gets digi'ed, and your own station recieves it back and igates it, the station that digi'ed it gets stripped out of the packet.
> This beacon is set to go out via 'RF only' but looks like is was sent direct to the APRS-IS. Also note the time stamp at the beginning of the payload as well as the timestamp from findu showing 5 seconds difference. There was one or more digi's in there
>  
> 20150607070734,KG4PID-14>APRX28,TCPIP*,qAC,T2TEXAS:/070729h3417.45N/08742.32W#PHG7250 Bear Creek, Al

This is the dup check issue already discussed. Regardless of whether you intended to send it RF only, if the path says TCPIP* it was sent directly to the APRS-IS, it was not IGated from RF. The q construct confirms it was a direct to internet packet. The path was not changed, it was the direct to internet packet which reached findU first (no surprise), somewhere along the line any RF IGated packets were removed by dup check.

You are connected to a tier 2 server, so the packet travelled through a number of servers before it got to findU, each can add a few tenths of a second of latency. The order in which a program performs tasks also gets involved. findU timestamps are not a reliable way to determine RF propagation time, or in this case to try to prove RF propagation occurred. 

Steve K4HG


_______________________________________________
aprssig mailing list
aprssig at tapr.org
http://www.tapr.org/mailman/listinfo/aprssig


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20150607/782060eb/attachment.html>