| |
ZL3AI > APRDIG 13.07.03 14:40l 267 Lines 11999 Bytes #999 (0) @ WW
BID : 1602-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jul 10, 2/4
Path: DB0FHN<DB0RGB<OK0PPL<OK0NAG<9A0BBS<VK6BBS<VK6HGR<ZL2BAU<ZL3VML
Sent: 030712/1330Z @:ZL3VML.#80.NZL.OC #:4231 [Chch-NZ] FBB7.00i $:1602-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: what causes this?
From: wes@johnston.net
Date: Thu, 10 Jul 2003 09:00:52 -0400 (EDT)
X-Message-Number: 11
My car is transmitting once a minute in the parking lot at work.
12:28:26,KD4RDB-15>SS5S0P,RELAY ,WIDE2-2,qAo,KC4PL :'lBUl Ev/]"4X}
12:29:27,KD4RDB-15>SS5S0P,RELAY ,WIDE2-2,qAo,KC4PL :'lBUl Ev/]"4Y}
12:30:28,KD4RDB-15>SS5S0P,RELAY ,WIDE2-2,qAo,KC4PL :'lBUl Ev/]"4\}
12:31:07,KD4RDB-15>SS5S0P,N4BAM-3*,WIDE2-1,qAo,KC4PL :'lBUl Ev/]"4_}
12:31:11,KD4RDB-15>SS5S0P,N5CWH-3 ,WIDE2* ,qAo,KC4ZGQ-10:'lBUl Ev/]"4Y}
12:31:32,KD4RDB-15>SS5S0P,RELAY ,WIDE2-2,qAo,KC4PL :'lBUl Ev/]"4X}
12:32:34,KD4RDB-15>SS5S0P,RELAY ,WIDE2-2,qAo,KC4PL :'lBUl Ev/]"4V}
I have padded these w/ spaces to make it easier to read. I see that my
station is transmitting about every 1 minute and 1 second. I see that
there is some "noise" in the next to the last digit of the MIC-e posit...
X, Y, \, _ ... ok I just assume that is the GPS "wandering".
Now look carefully at the packets beginning with 12:30:28.
I see that this packet seems to delay for 39 seconds (or could it be from a
previous transmission 1minute 40 seconds?). I know there is no packet to
be transmitted until 12:31:32, but for some reason, the 12:31:28 packet
makes its rounds (notice widen-n decrementing), and the last digit in the
mic-e position report is modified in each of those packets. I have tried
to match the contents of the packets with others from previous minutes and
can't. I know findu is removing dupes too... but that leads to the
question:
Why are the digipeaters modifying the mic-e part of my packets?
It could be that kc4pl and kc4zgq-10 are hooked to different servers in the
APRS-IS, but look at packets 12:30:28 and 12:31:07, they took different
routes on RF but came thru the same IGATE, and are different. The changes
*must* be happening on RF.
The two packets 12:31:07 and 12:31:11 have a perfect Wide2-1 to Wide2-0
transition and are 4 seconds apart, so you know they have *got* to be the
same packet.. yet the mic-e payload is different in them too.
Wes
----------------------------------------------------------------------
Subject: Re: what causes this?
From: "Tim Taylor" <Jakie@vcn.com>
Date: Thu, 10 Jul 2003 8:59:17
X-Message-Number: 12
OK, now I see why Wess is complaing of hidden transmitter problems. I
checked findu and sure enough he is transmitting once a minute plus or
minus. This is what causes conjection, he should be transmitting about
once every 10 to 30 minutes when parked and around 3 minutes when mobile.
Not once a minute. Transmitting so often causes a host of problems and
serves no purpose when parked.
Here's what I got off findu. The 47 is the number of times Wes transmitted
in one hour. This was a quick check so I don't know if he was parked or
mobile at the time. If he was moving this could be acceptable, if he was
stationary it's not. Every area has it's own requirements and this needs
to be put into concideration. Notice the objects around Wes and the number
of times they transmitted. Also note that I have seen people transmit
muuch more in an hour than Wes is. The information was taken at 7:45am
Mountain time.
KD4RDB-15 ** . . 33.88300 -80.64250 0.0 00:00:01:06 47.0
KC4PL ** ** . 33.98750 -80.49383 10.9 00:00:03:53 5.0
KD4RDB-1 ** ** . 33.93483 -80.40017 14.9 00:00:20:50 6.0
repeaters ** . . 33.92200 -80.33817 18.4 00:00:20:22 0.0
147015 ** . . 33.91283 -80.29117 21.2 00:00:20:23 0.0
N5CWH ** . ** 34.00100 -81.07167 26.7 00:00:15:28 7.0
N5CWH-2 ** . . 33.94400 -81.10050 27.7 00:00:04:23 3.0
73 Tim/KJ7AZ
----------------------------------------------------------------------
Subject: Re: what causes this?
From: wes@johnston.net
Date: Thu, 10 Jul 2003 10:00:12 -0400 (EDT)
X-Message-Number: 13
After digging thru the spec, I find that the ]"4X} on the end of my packets
represent the altitude. Still , I have to wonder why the digipeaters are
modifying my altitude.
Here's another example of a packet making it's rounds... note the last two
have obviously been modified on the air, and *should* be the same packet.
13:26:23,KD4RDB-15>SS5S0P,RELAY ,WIDE2-2,qAo,KC4PL:'lBUl Ev/]"4X}
13:26:45,KD4RDB-15>SS5S0P,KD4HTW-9*,WIDE2-1,qAo,KC4PL:'lBUl Ev/]"4Y}
13:26:46,KD4RDB-15>SS5S0P,KD4HTW-9*,WIDE2-1,qAo,KC4PL:'lBUl Ev/]"4[}
If someone had PASSALL set to on and were digipeating corrupted packets,
why only would the corruption only be the next to the last byte of the
mic-e packet?
----------------------------------------------------------------------
Subject: Re: what causes this?
From: wes@johnston.net
Date: Thu, 10 Jul 2003 10:18:54 -0400 (EDT)
X-Message-Number: 14
Ordinarily, I TX once every 30 minutes when parked. Today is a test. I
have also dragged kc4pl into this test too. He also ordinarily TX's every
30 minutes when parked.
Yesterday a question was raised about positions not getting it due to
picket fencing and other moving phenomena, or stationary problems (ie
hidden transmitters). So for today, and ONLY today, I am TX'ing once a
minute while stationary so that I can gather stat's about how many times a
mobile station can get into the network when not moving. So far, I show 21
misses in 120 minutes on my station which is in a rural area. This ain't
too bad. I'm about to lower my mobile's power to 5w and see what a change
that makes.
kc4pl has been on one min interval for 54 minutes and has 12 missed
positions. He's in a more urban (and busy) area.
Hey, scientific though involves coming up with a hypothesis and proving or
disproving it. <grin>
Wes
----------------------------------------------------------------------
Subject: Re: what causes this?
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Thu, 10 Jul 2003 09:40:07 -0500
X-Message-Number: 15
There may not be any modification occurring on RF (or anywhere else, for
that matter). When transmitting with a path of that takes you through a
minimum of 3 digi's (1 RELAY, 2 WIDEN-N), delays can occur. I have seen
2 instances where these delays can be extensive. The one you may be
seeing here is a WIDEN-N digi holding packets until a clear space
occurs. With the Kantronics TNC's, I have seen this delay be up to a
minute or more later. You can see this by monitoring the RF side
directly and looking for a digi "dumping" a lot of packets all at once.
I have also seen where packets show up on APRS-IS upwards of 6 or 7
minutes later. I saw this while traveling over central Texas. I am not
sure that the IGate sysops ever discovered what was causing the delay.
I was able to eliminate the APRS-IS servers from the equation, however.
I don't believe you are seeing data corruption. I think you are seeing
delays introduced for possibly multiple reasons.
73,
Pete Loveall AE5PL
pete@ae5pl.net
----------------------------------------------------------------------
Subject: Re: what causes this?
From: David L Norris <kg9ae@webaugur.com>
Date: 10 Jul 2003 10:39:10 -0500
X-Message-Number: 16
On Thu, 2003-07-10 at 09:40, AE5PL Lists wrote:
>With the Kantronics TNC's, I have seen this delay be up to a
>minute or more later. You can see this by monitoring the RF side
>directly and looking for a digi "dumping" a lot of packets all at once.
I see delays of many hours from time to time around here with some
Kantronics-based digis. A couple of the digis in the area get locked up
reasonably often with stuck transmitters and band openings. Looking
into one such case I found that the KPC-3 has a CD mode which detects
any RX energy (CD INTERNAL, I believe) rather than actual data. That
was causing the digi to hold-off for a weak, dead carrier (stuck serial
port PTT, I presume). Once the carrier was cleared the digi dumped a
buffer full of packets. The digi was changed to detect data (CD
SOFTWARE) a few days later. I don't believe there have been any
problems since.
--
David Norris, ARS: KG9AE
http://www.webaugur.com/dave/kg9ae/
ICQ - 412039
----------------------------------------------------------------------
Subject: Re: what causes this?
From: Bill Owens N2RKL <bill-tapr@owensfamily.org>
Date: Thu, 10 Jul 2003 11:46:52 -0400
X-Message-Number: 17
On Thu, Jul 10, 2003 at 10:00:12AM -0400, wes@johnston.net wrote:
>After digging thru the spec, I find that the ]"4X} on the end of my packets
>represent the altitude. Still , I have to wonder why the digipeaters are
>modifying my altitude.
Are you sure that it isn't just your altitude drifting around? My GPS does
that, as I think most of them do. I've heard of some having barometric
sensors to try to smooth out the altitude variations, but mine is much
too cheap for a feature like that ;)
Here's what Xastir reports for you when I grabbed positions from findu
for the last 22 hours:
Packets received: 158 Last Heard: 07/10/2003 11:36:57
Heard last via File, and has moved
Data path: SS5S0Q,RELAY,WIDE2-2,qAo,KC4PL
Comments: TM-D700 Mic-E Enroute <br>
Current Power Gain: default (9W @ 6.1m HAAT, 3dB omni, range 10.0km)
Altitude: 67m Course: 041 Speed: 0.0 km/h
Distance from my station: 9138.8 km Bearing from my station: 304.2
Last Position:
07/10 11:36 33 53.010N 080 38.570W 67m 0km/h 41 EM93qv
07/10 11:36 33 53.000N 080 38.570W 57m 0km/h 41 EM93qv
07/10 11:36 33 53.010N 080 38.570W 65m 0km/h 41 EM93qv
07/10 11:36 33 53.000N 080 38.570W 75m 0km/h 41 EM93qv
07/10 11:36 33 53.000N 080 38.570W 77m 0km/h 41 EM93qv
07/10 11:36 33 53.010N 080 38.570W 50m 0km/h 41 EM93qv
07/10 11:36 33 53.000N 080 38.570W 61m 0km/h 41 EM93qv
07/10 11:36 33 53.000N 080 38.570W 58m 0km/h 41 EM93qv
07/10 11:36 33 53.000N 080 38.570W 74m 0km/h 41 EM93qv
07/10 11:36 33 53.000N 080 38.570W 60m 0km/h 41 EM93qv
07/10 11:36 33 53.000N 080 38.570W 126m 0km/h 41 EM93qv
07/10 11:36 33 53.000N 080 38.570W 73m 0km/h 41 EM93qv
07/10 11:36 33 52.980N 080 38.550W 280m 0km/h 41 EM93qv
07/10 11:36 33 53.000N 080 38.570W 72m 0km/h 41 EM93qv
07/10 11:36 33 53.010N 080 38.570W 68m 0km/h 41 EM93qv
07/10 11:36 33 53.010N 080 38.570W 64m 0km/h 41 EM93qv
07/10 11:36 33 53.010N 080 38.570W 66m 0km/h 41 EM93qv
07/10 11:36 33 53.010N 080 38.570W 67m 0km/h 41 EM93qv
07/10 11:36 33 53.000N 080 38.570W 66m 0km/h 41 EM93qv
07/10 11:36 33 53.000N 080 38.570W 63m 0km/h 41 EM93qv
07/10 11:36 33 53.010N 080 38.570W 72m 0km/h 41 EM93qv
07/10 11:36 33 53.010N 080 38.570W 70m 0km/h 41 EM93qv
07/10 11:36 33 53.010N 080 38.570W 71m 0km/h 41 EM93qv
07/10 11:36 33 53.010N 080 38.570W 69m 0km/h 41 EM93qv
07/10 11:36 33 53.000N 080 38.570W 70m 0km/h 41 EM93qv
07/10 11:36 33 53.000N 080 38.570W 67m 0km/h 41 EM93qv
07/10 11:36 33 53.000N 080 38.570W 62m 0km/h 41 EM93qv
07/10 11:36 33 53.000N 080 38.570W 65m 0km/h 41 EM93qv
07/10 11:36 33 53.000N 080 38.570W 64m 0km/h 41 EM93qv
07/10 11:36 33 53.000N 080 38.570W 68m 0km/h 41 EM93qv
07/10 11:36 33 53.000N 080 38.570W 69m 0km/h 41 EM93qv
07/10 11:36 33 53.000N 080 38.560W 76m 0km/h 41 EM93qv
07/10 11:36 33 53.000N 080 38.570W 71m 0km/h 41 EM93qv
You had the usual location dance as well, that has been explained to me
as having to do with the constellation visible at any moment, multipath,
varying horizon visibility and other factors which confuse the GPS into
thinking it has moved. Note that the timestamps are meaningless, since
Xastir doesn't ask findu for the timestamped version of the positions
(at least, not yet ;)
Bill N2RKL
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
