[aprssig] KPC3+ induced errors

Wed Mar 16 15:21:32 EDT 2011

Thanks for looking at the data Keith.

Let me explain that the data I sent in my last post was from early in the
first flight, KC0YA-11, before the second payload, AE0SS-11, was fired up.
So as not to have the two payloads as a possible cause for the delay.

We see the delay right after launch of the first balloon.  I think the
KPC3+'s in both payloads have EOSS as their UIDigi or MyNode I believe.  I
don't maintain the payloads, so I'm guessing a bit.  I do have the KC0YA-11
payload here and I'll dig into it and pull the configuration to see.  I
don't believe the payload KPC3+'s are the problem as all other Igates pass
the balloon packets just find.

To answer your questions, "Looking below, where was the EOSS digi located?
Was it on the ground
or in the air?" 

The EOSS digi was in the air for both KC0YA-11 and AE0SS-11.  We do that so
that when we fly two balloons the second balloon payload will act as a digi
to transmit the "payload-on-the-ground's" position. 

You wrote, " I don't see an asterisk by the EOSS digi, so I'm
assuming that all three above were heard direct."

That is correct. 

You wrote, " I searched all of the beacons that you posted. There weren't
any duplicates, but going by the
time stamps, some were out of order."

My bad.  The snapshot I sent didn't cover enough time to be able to see that
the late KC0D-3 packets were indeed dups of earlier packets.

You wrote, "Do you know if the EOSS digi was used for any of the
beacons? Just going by the data that you posted, it was not..."

No. the EOSS digi was in the air and it was only digi'ing the other balloon
and the T&R team members of the ground.

You wrote, "Does anyone know of any software that can receive data on a
serial port and spit
it out on a different virtual port?"

A simple RS-232 "Y" cable should do it.  Come from the serial port on the
D710 to the "Y" cable to two different computers, one running UI-View and
the other a simple comm. Program.  Open Terminal on UI-View and both
terminal screens should see the same thing.  What we really need to do, or
Mark should do, is put an Ethernet protocol analyzer on the UI-View machine
and watch to see when a packet come into the radio and on through to UI-View
and then passed out the Ethernet port.  If all that works in a timely
fashion, then there is a possibility, however remote, that the packets are
being heldup in the carrier's network.

Thanks again Keith for working on this with us.

Larry K0ANI

-----Original Message-----
From: aprssig-bounces at tapr.org [mailto:aprssig-bounces at tapr.org] On Behalf
Of Keith VE7GDH
Sent: Wednesday, March 16, 2011 12:33 PM
To: TAPR APRS Mailing List
Subject: Re: [aprssig] KPC3+ induced errors

Larry K0ANI wrote...

> You asked about the Igater that was using the Kenwood D710 on the EOSS
> flights Saturday.  It was Mark, KC0D, a well know and very competent HAM.
> He was running his Igate unattended as he was out in the field as part of
> the Tracking and Recovery team.  We have had conversations about this
issue
> and he is at a loss for what is happening as are we all.

Looking below, where was the EOSS digi located? Was it on the ground
or in the air?

> Here is a snapshot of the telemetry from EOSS-159, the first flight of the
> day.  Mark's Igate is kc0d-3 in the snapshot.  I haven't broken out the
> delays to measure the delay time, but I don't think it matters as there is
> an obvious problem that can be seen in the time stamps and the altitudes
> reported.

Keep in mind that it the data below was obtained from the APRS-IS, there
could be a lot
of dupes that were thrown out. If dupes were delayed by more than 30
seconds, they would
show up on the APRS-IS.

Note the time stamps in the $GPGGA sentences.

KC0YA-11>APRS,EOSS,qAR,KC0D-3:$GPGGA,135316,4028.3444,N,10457.8329,W,1,08,1.
00,1950.0,M,-21.0,M,,*77

KC0YA-11>APRS,EOSS,qAR,KC0VJE:$GPGGA,140228,4027.8067,N,10453.3921,W,1,10,0.
75,5529.5,M,-21.1,M,,*7D

KC0YA-11>APRS,EOSS,qAR,KC0D-3:$GPGGA,135346,4028.3376,N,10457.8609,W,1,08,1.
00,2131.5,M,-21.0,M,,*7A

The 135346 beacon was obviously sent after the one at 135316 and before the
one at 140228
but was gated after the 140228 beacon. The first and third beacons above
were gated by KC0D-3,
but the one in between was gated by KC0VJE. I don't see an asterisk by the
EOSS digi, so I'm
assuming that all three above were heard direct.

I searched all of the beacons that you posted. There weren't any duplicates,
but going by the
time stamps, some were out of order. Do you know if the EOSS digi was used
for any of the
beacons? Just going by the data that you posted, it was not... i.e. there
wasn't an asterisk by
it indicating that the digi path had been used. If that is correct, the
delays would be attributed
to the IGate... whether it was the TNC or the IGate software being used
would have to be 
determined.

Fortunately, the data for KC0YA-11 can still be seen at aprs.fi...

http://aprs.fi/?c=raw&call=KC0YA-11&limit=1000

I can see the beacon from 135346 gated by KC0VJE at 13:53:51 UTC. It was
gated again
by KC0D-3 at 14:02:59 UTC, showing a delay of about 10 minutes. I don't see
any asterisk
indicating that the digi path was used. I'll paste the two beacons below.

2011-03-12 13:53:51 UTC:
KC0YA-11>APRS,EOSS,qAR,KC0VJE
:$GPGGA,135346,4028.3376,N,10457.8609,W,1,08,1.00,2131.5,M,-21.0,M,,*7A

2011-03-12 14:02:59 UTC:
KC0YA-11>APRS,EOSS,qAR,KC0D-3
:$GPGGA,135346,4028.3376,N,10457.8609,W,1,08,1.00,2131.5,M,-21.0,M,,*7A
[Location changes too fast (>500 km/h)]

Because raw data is only available for a few days on aprs.fi, I just grabbed
all that
was available, amounting to the last 900 beacons. I've saved it in a text
file here, so that
will always be available. Searching the page for an asterisk by the digi
path, I see
that that EOSS was never used. However, some beacons were to APRS and some
were to BEACON. The ones sent to BEACON were telemetry beacons, and they
went out with a path of WIDE2-2.

Focusing on one of the later beacons...

2011-03-12 16:10:53 UTC:
KC0YA-11>APRS,AE0SS-11*,qAR,N0PSJ
:$GPGGA,161047,4027.5547,N,10344.1034,W,1,08,1.12,1402.3,M,-22.8,M,,*78

The time stamp according to the beacon was 161047. It was digi'd by AEOSS-11
and
gated by N0PSJ 6 seconds later at 16:10:53 UTC. The same beacon was then
gated
by KC0D-3...

2011-03-12 16:14:19 UTC:
KC0YA-11>APRS,AE0SS-11*,qAR,KC0D-3
:$GPGGA,161047,4027.5547,N,10344.1034,W,1,08,1.12,1402.3,M,-22.8,M,,*78

Both N0PSJ and KC0D-3 heard it via the AEOSS-11 digi, so any delay
introduced
by the digi would be seen by both IGates... in other words, the two IGates
heard the
beacon from the digi at the same time. The second copy was gated at 16:14:19
which
works out to a delay of 3 minutes 26 seconds. Perhaps some coordinated tests
could be done with KC0D-3. I've done this in the past. Just get together on
UHF or HF
or whatever, send a beacon, preferably with a time stamp, and get KC0D-3 to
watch
the IGate and tell you when he sees the beacon. He appears to be running
UI-View, so
it should be an easy matter for him to open the terminal window and set the
filter
to exclude "Internet" traffic (this is the terminal window filter, not the
one used to
connect to the APRS-IS) so he is watch RF traffic only to makes things
easier to
view.

Does anyone know of any software that can receive data on a serial port and
spit
it out on a different virtual port? I'm just trying to think of a way for
KC0D-3 to view
the serial data even before it gets to UI-View. I suppose a "low tech" way
of seeing
delays would be to watch the S meter on the radio and then watch the
terminal
window to see when the beacon shows up there. For delays that were in the
minutes instead of seconds, a check somewhere like aprs.fi (that really gets
data
from the APRS-IS) could provide a further confirmation that the beacon got
to the
APRS-IS moments after it was seen in the terminal window.

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

_______________________________________________
aprssig mailing list
aprssig at tapr.org
https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig