| |
ZL3AI > APRDIG 22.07.06 01:21l 356 Lines 14529 Bytes #999 (0) @ WW
BID : 8421-ZL3AI
Read: GUEST
Subj: [APRSSIG] Vol 25 #19, 2/4
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<DK0WUE<7M3TJZ<ZL2BAU
Sent: 060721/2248Z @:ZL2BAU.#87.NZL.OC #:59795 [Waimate] $:8421-ZL3AI
From: ZL3AI@ZL2BAU.#87.NZL.OC
To : APRDIG@WW
Message: 11
Date: Tue, 18 Jul 2006 14:58:10 -0600
From: Joel Maslak <jmaslak-aprs_at_antelope.net>
Subject: Re: [aprssig] vehicle laptop mount for APRS rig
On Jul 18, 2006, at 10:13 AM, Jason Winningham wrote:
>Can anyone recommend a vehicle laptop mount?
>
>I find myself going mobile with the laptop more and more, and it's
>fairly unmanageable.
>
>I'd also be interested in hearing about success with display
>mounts, especially touchscreens, for mobile computing rigs.
Note that in many jurisdictions, laptops that are visible to the driver are
illegal. There are exceptions for "navigation systems" in some places, but
you should check your laws first and make sure you comply.
Also, there is no such thing as a temporary mount for anything in a car -
or at least shouldn't be. You should do this right or not at all. I would
not want to get hit by a laptop in an accident... Note that "easily
removable" and "doesn't modify the car's structure" are not the same as
"temporary". But for something as heavy as a laptop, it's almost a given
that it will need to attach to a seat attachment bolt or other similarly
sturdy mount.
As others have mentioned, watch out for those airbags.
------------------------------
Message: 12
Date: Wed, 19 Jul 2006 07:19:15 +1000
From: "Andrew Rich" <vk4tec_at_tech-software.net>
Subject: RE: [aprssig] vehicle laptop mount for APRS rig
Where does your wife sit ?
Andrew Rich
Amateur radio callsign VK4TEC
email: vk4tec_at_tech-software.net <mailto:vk4tec_at_tech-software.net>
web: http://www.tech-software.net
Brisbane AUSTRALIA
-----Original Message-----
>From: Drew Baxter [mailto:droobie_at_maine.rr.com]
>
>I like my Jotto Desk for what it is. They're sometimes cheap to have
>on EBay and other places. They have vehicle specific foot mounts for
>many vehicles as well.
>
>www.jottodesk.com.
>
>If you want to see one installed then check out
>http://home.gwi.net/~droobie/rdfview.jpg. Pretty old photo but it
>shows how it goes. In my case I had to bolt right into the firewall
>where the transmission is because they didn't make a custom
>foot. Maybe they do for my Maxima.. :)
>
>I think RAM Mount makes some laptop trays too. I wouldn't use
>anything that doesn't have some sort of locking feature to lock it
>down to the platform.
>
>--Droo, K1XVM
------------------------------
Message: 13
Date: Tue, 18 Jul 2006 17:26:19 -0400
From: Drew Baxter <droobie_at_maine.rr.com>
Subject: RE: [aprssig] vehicle laptop mount for APRS rig
Don't have one, hasn't been a problem.. :) I had a girlfriend but I
decided that she could sit in tow. I think that was a fair deal
considering how much of a horrible person she turned into. :D In the
future I'll screen these things better, find out what I'm getting into.
In all seriousness though.. The Jotto Desk can be raised and lowered, so
there's enough clearance for someone to sit there if need be. It also
comes out pretty easy.
I still have the truck, but the desk and the radio, etc. are out of it now.
I'm working on getting my D700 into my 2002 Nissan Maxima I bought off Ebay
in October. So far I've made a great headliner mount for the screen.
Hopefully I'll get the other electronics installed soon.
My 1995 Nissan XE-V6 Pickup doesn't have airbags. I think they're a pretty
stupid thing to have in a truck anyway, especially considering how often I
go mudding with it. They'd be sure to go off I figure.
--Droo, K1XVM
At 05:19 PM 7/18/2006, Andrew Rich wrote:
>Where does your wife sit ?
------------------------------
Message: 14
Date: Tue, 18 Jul 2006 16:28:22 -0500
From: "John Habbinga" <kc5zrq_at_gmail.com>
Subject: Re: [aprssig] vehicle laptop mount for APRS rig
>not the same as "temporary". But for something as heavy as a laptop,
>it's almost a given that it will need to attach to a seat attachment
>bolt or other similarly sturdy mount.
When using the bean-bag pillow desk, I hit the brakes hard, and I mean
really hard, and the laptop stayed put. Laptop is about 8 lbs, the pillow
might weigh more. I also used it in a van, setting on the center console,
as we led the lead cyclist around a triathlon course. If I didn't have
that, then I would have had to hold the laptop on my lap. That certainly
wouldn't have been desirable. It makes me wonder why anyone calls them
laptops.
------------------------------
Message: 15
Date: Tue, 18 Jul 2006 17:33:28 -0400
From: Drew Baxter <droobie_at_maine.rr.com>
Subject: Re: [aprssig] vehicle laptop mount for APRS rig
Apple takes care to call their new ones Notebook in the manual, namely
because the only assurance putting the new Macbooks and Macbook Pros on
your lap is sterility or burns. Mine in particular tends to be around
150-180 degrees. I think it even says in there NOT to use it on your lap,
for those very reasons.
It's probably not just them. I have a few year old ones from other
companies that get hot enough that you probably don't want your hand on it
for very long. I'm not surprised most of the people I know seem to have
those cooling pads nowadays attached to the bottom of them.
--Droo, K1XVM
At 05:28 PM 7/18/2006, John Habbinga wrote:
>It makes me wonder why anyone calls them laptops.
------------------------------
Message: 16
Date: Tue, 18 Jul 2006 16:57:58 -0500
From: "Tim Cunningham" <tim_cunningham_at_mindspring.com>
Subject: Re: [aprssig] IGate to APRS-IS data transfer delays
Bob,
The intent was to segregate the IGate delay issues from the DCD issues. I
agree that there are some DCD issues, but if you go back to the beginning of
this discussion I weeded out the fact that there were no major DCD issues
with the examples I provided. They were qualified for the 2 IGates in
question where there was a delay problem. This is not to say there are no
DCD delays. We merely qualified one digipeater at 2 seconds which is not
significant. The IGate delays in the examples far exceeded any DCD delay.
When 2 IGates hear the same packet, what is an acceptable time frame for the
IGate to transfer the packet to the APRS-IS ? Your third fact needs
explanation. I provided 2 example where one IGate took 1min 11sec longer and
another around 10mins longer to pass the same data from the same packet
heard by 2 different IGates. Is this amount of delay acceptable? Or, do we
really care how long it takes data to get to the APRS-IS from an IGate?
I am not sure how you can say I am jumping the gun if you read the posts I
presented. Perhaps, I assume too much. In each case data was presented there
was supporting data that highly suggested the IGate was the source of delay
by comparing the delay when 2 IGates heard the same data. It does not take
long to see where the problem resides. When 2 IGates hear the same packet
and the delay in the time it takes for that data to reach the APRS-IS is
significantly different, then something is wrong. You suggest it takes
seconds and that is not the case in my examples. Then again, maybe we have
to accept bouncing position reports when utilizing the Internet connection.
The bouncing position report started this discussion. Data correlation got
to the root cause.
One more time...
Example #1:
20060715003528,W4GPS-7>APZ19,WIDE2-2,qAo,N8DEU-4:!3438.07NS08630.74W#PHG5630/W3L
,An
Huntsville Alabama
20060715003639,W4GPS-7>APZ19,WIDE2-2,qAo,KG4PID-15:!3438.07NS08630.74W#PHG5630/,
W3ALn
Huntsville Alabama
20060715004448,W4GPS-7>APZ19,NT4UX-2,NT4UX-3,WIDE2*,qAR,KQ4TV-1:!3438.07NS086304
.7W#PHG5630/W3,ALn
Huntsville Alabama
In the above example 2 IGates hear the same packet from W4GPS-7. They are
N8DEU-4 and KG4PID-15. It is the same packet, because the beacon to WIDE2-2
is on a 29 minute cycle. If it is not the same packet the problem is far
more serious. KG4PID-15 sends the same data to the APRS-IS 1min 11sec later
than N8DEU-4. If this were a mobile station beaconing every 1 minute then
you would see position oscillation on FINDU and from the APRS-IS. It is this
simple. There are no digipeaters involved in the first 2 packets, except for
the digipeater originating a beacon.
Now the third packet has 2 digipeaters involved before the KQ4VT-1 IGate
sends the packet to the APRS-IS 9min 20sec later. This is a harsh delay, but
I think Bruce stated he may have fixed a time sync problem at KQ4VT-1. How
did I qualify KQ4VT-1 IGate was the source of the delay. Look at example #2:
Example #2:
1 -
20060715205225,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAo,KQ4TV-3:!3607.19N/08644.47W2
j02/005/A=000000
2 -
20060715205516,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAR,KQ4TV-1:!3607.08N/08644.51W0
j24/000/A=000000
3 -
20060715210932,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAo,KQ4TV-3:!3607.12N/08644.43W2
j20/005/A=000665/Monitoring
443.450+ 107.2 - IRLP 4767
4 -
20060715212237,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAo,KQ4TV-3:!3607.16N/08644.59W4
j36/020/A=000557
5 -
20060715212432,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAo,KQ4TV-3:!3607.45N/08645.03W3
j03/013/A=000593/Monitoring
443.450+ 107.2 - IRLP 4767
6 -
20060715212738,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAR,KQ4TV-1:!3607.16N/08644.59W4
j36/020/A=000557
7 -
20060715212947,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAR,KQ4TV-1:!3607.45N/08645.03W3
j03/013/A=000593/Monitoring
443.450+ 107.2 - IRLP 4767
8 -
20060715213045,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAo,KQ4TV-3:!3607.50N/08645.13W4
j30/016/A=000636
9 -
20060715213056,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAo,KQ4TV-3:!3607.54N/08645.14W5
j09/011/A=000623
10 -
20060715213136,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAo,KQ4TV-3:!3607.54N/08644.73W9
j04/031/A=000593
11 -
20060715213252,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAo,KQ4TV-3:!3607.14N/08644.56W2
j15/019/A=000511
12 -
20060715213725,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAR,KQ4TV-1:!3607.50N/08645.13W4
j30/016/A=000636
13 -
20060715213917,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAR,KQ4TV-1:!3607.54N/08644.73W9
j04/031/A=000593
Look closely at the above data. Packets arriving at KQ4VT-1 and KQ4VT-3 from
the same digipeater have a time delta from when they enter the APRS-IS. The
data clearly shows something is wrong between KQ4TV-1 and the APRS-IS in
respect to delays. If you follow the packets you will see KQ4TV-3 gates a
packet and then KQ4TV-1 gates the same packet from the same digipeater at
NT4UX-3, but KQ4TV-1 seems to always be lagging significantly and it varies
up to 10 minutes. So, this is just another piece of data that suggest this
problem is not a DCD problem. Again, two IGates hear the same data at the
same time from the same digipeating station, but they arrive on the APRS-IS
at significantly different times. This data was utilized to correlate the
delay in example #1. Of course, we did not qualify the delays for NT4UX-2
and NT4UX-3 digipeaters. Remember, I was focused on IGate delays. I am not
saying the DCD of these 2 digipeaters is not important, but when I talked to
Bruce I was confident they were set correctly and they were not observing
and major packet delays from these digipeaters.
KQ4TV-JS is the javAPRSSrvr and KQ4TV-1 is the (KISS) TNC-Radio connected to
it. KQ4TV-3 is the xastir (on Mac) station with radios on 144.39 and 144.34.
Both machines are at Bruce's house. While time sync was working fine on the
KQ4TV-3 station, there was a problem with the javAPRSSrvr but Bruce thinks
he has it fixed.
>From example #2. The time lag is as follows:
Line 1 and Line 2 = 2min 51sec
Line 4 and Line 6 = 5min 01sec
Line 5 and Line 7 = 5min 15sec
Line 8 and Line 12 = 6min 40sec
Line 10 and Line 13 = 7min 41sec
Example #3:
20060714194906,N8DEU-12>S4TX1X,WIDE1-1,WIDE2-1,qAo,N8DEU-4:'rEll"9j/]"7+}
20060714195019,N8DEU-12>S4TX1X,W4GPS-7,WIDE1,KU4WW-1*,WIDE2,qAo,KG4PID-15:'rEllj
"9/]"7+}
20060714195939,N8DEU-12>S4TX1X,W4GPS-7,WIDE1,NT4UX-2,WIDE2*,qAR,KQ4TV-1:'rEll"9]
j/"7+}
We established KG4PID-15 transferred data to the APRS-IS 1min 11sec after
N8DEU-4 in example #1. In this example we see that 2sec are added if a
packet is digipeated by KU4WW-1 on its way to KG4PID-15. The is correlated
data based on the previous time lag as we see in numerous other log files.
So, I pretty much eliminated the digipeater at KU4WW-1 as being a delay
mechanism through correlation of other data that echoes what we see here. It
is a lot of work and it takes a lot of time to get to the root.
The DCD problem is an easy fix and that is why I am excluding it in this
post. It is the IGate delay that has gone without understanding of why it
happens. There is no standard on how long it takes to transfer a packet from
an IGate to the APRS-IS. You state it takes seconds and I concluded through
example and log files that it is not seconds from some IGates. On the
contrary, it can be minutes. The question remains, what is a acceptable time
frame from an IGate to transfer data to the APRS-IS?
Here is a snapshot of some core server statistics based on port usage:
Servers First Second Third Totals
Port 23 57 68 38 163 29.74%
Port 1313 1 0 0 1 0.18%
Port 1314 5 11 3 19 3.47%
Port 10151 0 18 12 30 5.47%
Port 10152 52 29 40 121 22.08%
Port 10154 1 4 7 12 2.19%
Port 10155 3 7 3 13 2.37%
Port 10156 0 0 4 4 0.73%
Port 10157 0 0 1 1 0.18%
Port 10158 0 0 1 1 0.18%
Port 10159 0 0 4 4 0.73%
Port 14578 7 0 0 7 1.28%
Port 14579 0 1 5 6 1.09%
Port 14580 23 37 106 166 30.29%
149 175 224 548
27.19% 31.93% 40.88%
30.29% of the IGates are using the user defined port of 14580. I think if
most IGates used port 14580 and set a limited range of 200km or less to
limit the amount of data coming into their IGate, they could realize a
performance boost. This is merely a suggestion. We use the "r/34/-86/200
t/n" filter option on port 14580 with the core servers to limit the amount
of data our IGate needs to process and it does make a difference for us.
We have established that IGate to APRS-IS delays exist. Now the question is
what can be done to address it.
Does an IGate need to be processing incoming data at all unless it is
specific to their area? There seems to be a huge potential with IGates using
port 14580 and limiting their incoming data. We observed a fairly dramatic
improvement on this end.
This post gets fairly complex, distorted, and it goes off in too many
directions if you try to bring DCD issues into the topic. Please try to keep
DCD issues out of this discussion. It is another topic even though it may
relate to delays.
73's,
Tim - N8DEU
Huntsville, Alabama
------------------------------
Read previous mail | Read next mail
| |
