| |
ZL3AI > APRDIG 27.01.04 13:13l 251 Lines 9651 Bytes #999 (0) @ WW
BID : 2737-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jan 24, 2/4
Path: DB0FHN<DB0THA<DB0ERF<DB0FBB<DB0GOS<ON0AR<WB0TAX<VK7AX<ZL2BAU<ZL3VML
Sent: 040127/1045Z @:ZL3VML.#80.NZL.OC #:17685 [Chch-NZ] FBB7.00i $:2737-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Attended vs Unattended
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Sat, 24 Jan 2004 15:56:56 +0100
X-Message-Number: 9
At 13:25 18-1-2004 -0500, Richard Amirault wrote:
>If the indicator is changed to something the operator must do .. toggle a
>key (I'm here/I'm not here) then you have the problem of operator error.
>Forgetting to "check out" when walking away, or forgetting to "check in".
Maybe it can be automated? As long as the mouse is moving and keys are
touched the operator is present. If there is no activity for 15 minutes,
the operator is absent. Of course this should be configurable in case the
APRS station runs on a machine in a corner and alerts the user with a signal.
Maybe it would be a nice HAM project to build a pressure sensor in you
chair (to detect you're sitting behind the desk, must be "cat" proof) or
wire an infra-red detector (alarm system rip-off) to the PC to detect human
presense.
Maybe it could be tied in with the screen-saver for windows systems.
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Re: Vehicle Telemetry
From: <mike@hatzakis.net>
Date: Sat, 24 Jan 2004 08:02:34 -0800
X-Message-Number: 10
Wouldnt you need many a/d conveters and what would you sense in the engine?
Seems that's the more challenging part...
----------------------------------------------------------------------
Subject: Re: UI-VIEW TActical Display
From: Bob Bruninga <bruninga@usna.edu>
Date: Sat, 24 Jan 2004 11:41:21 -0500 (EST)
X-Message-Number: 11
On Sun, 15 Dec 2002, Andrew Rich wrote:
>I was at a mesuem the other day and saw a radar tactical display.
>I thought to myself there is no reason why UI-VIEW could not look the same.
>I turned my map to black, and set the symbols to something compatible.
>I came up with this :-
1. [Image: tact.JPG] (6.7KB) ""
Yep, that is why APRSdos maps always had a black background. They
evolved from my 20 year Naval carreer of watching tactical displays in
CIC. That is also why APRSdos has Range Scales and Range Rings.
I always thought such a live display on all of those Museum ships using
APRS and and old PC would be of interest to visitors and fun for the HAMS
that man those ships...
Bob
----------------------------------------------------------------------
Subject: Re: Attended vs Unattended
From: "Scott Johnson" <kd5mhm@kd5mhm.org>
Date: Sat, 24 Jan 2004 10:42:11 -0600
X-Message-Number: 12
Why not use the thingy that companies are starting to deploy that detects an
employee close to their PC (assuming therefore that they are 'working')?
----------------------------------------------------------------------
Subject: Re: Re: APRS Icon help - Findu - PcSAT
From: Steve Dimse <k4hg@tapr.org>
Date: Sat, 24 Jan 2004 12:11:47 -0500
X-Message-Number: 13
On 1/24/04 at 8:12 AM Spider <spider@rivcom.net> sent:
>What is interesting is that findu displays the position correctly, telling
>me it is processing the compressed packet. It's just not displaying the map
>SYMBOL correctly from what it processed. And, you see this on many
>stations. Both UI-View and Xastir decode this correctly. So if you are
>using a grid square location and your findu position is correct on the map,
>then it must have some sort of issue with that as well.
I was unaware that that findU was not processing the icons, for a long time I
did nothing with the icon foeld, so some packets never got icon parsing added
in. It is now fixed for both the compressed format and grid in status. Let me
know if there are any problems with this...
Steve K4HG
----------------------------------------------------------------------
Subject: RE:RE: USB Adapters
From: Dave VanHorn <dvanhorn@cedar.net>
Date: Sat, 24 Jan 2004 12:34:52 -0500
X-Message-Number: 14
I have tried a number of serial/usb devices, and the one that ALWAYS works,
is the Edgeport.
I've had 4 port units on ebay for as little as $10, and they do make
8 port as well, though they end up closer to $100.
I have about half a dozen in service now, and just no problems.
You can turn off "plug and play" discovery, so that winders won't try to
hose you when it thinks it sees an MS Ballpoint mouse in your GPS stream.
----------------------------------------------------------------------
Subject: Re: Vehicle Telemetry
From: "Scott Miller" <scott@3xf.com>
Date: Sat, 24 Jan 2004 09:41:32 -0800
X-Message-Number: 15
They're already there. I think what Bob's talking about is connecting to an
OBD-II (On-Board Diagnostic) port. See
http://www.scantool.net/faq/which_protocol.htm.
Good luck finding the proper documentation. Last time I looked it was
pretty difficult. They were supposed to pass some legislation requiring
manufacturers to release information on their protocols - locking out the
small mechanics was found to be anti-competitive. So maybe it's easier to
find now. Why they couldn't have just used a DB-9 running something like
ASN.1 over RS-232 I don't know. Would've made it a lot easier...
For a teen driver, Bob, what you really need is something like this:
http://www.drivecam.com/. Be sure to check out the demo videos at
http://www.drivecam.com/drivecam-videos.html.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Vehicle Telemetry
From: <mike@hatzakis.net>
Date: Sat, 24 Jan 2004 09:56:09 -0800
X-Message-Number: 16
All I have to say it, wow. Time to et my laptop out and give it a try.
Wonder if the OBD standards apply to the european cars... Thanks...! MH
----------------------------------------------------------------------
Subject: Re: Vehicle Telemetry
From: Jeff King <jeff@aerodata.net>
Date: Sat, 24 Jan 2004 13:54:21 -0500
X-Message-Number: 17
Here ya go:
http://www.elmelectronics.com/DSheets/ELM323DS.pdf
It is a OBD2 to RS-232 interface chip.... actually a custom PIC the guy is
selling. About $xx + a little glue logic.
http://www.elmelectronics.com/index.html (under products)
Key words to use in other searches are "scan tools" which auto hobbyists use
to read OBD2 codes.
--
Jeff King, jeff@aerodata.net on 01/24/2004
----------------------------------------------------------------------
Subject: Re: Attended vs Unattended
From: Bob Bruninga <bruninga@usna.edu>
Date: Sat, 24 Jan 2004 14:01:27 -0500 (EST)
X-Message-Number: 18
On Sat, 24 Jan 2004, Henk de Groot wrote:
>>For what it's worth, here is the rule that APRSdos uses to determine
>>"mobiles", Weather and DIGIS:
>>
>> Mobiles if any of these Primary symbols: '<=>0COPRSUXY[^abefgjkpsuv
>> Mobiles if any of these altrnte symbols: /0>AKS^nsuv
>> Weather if any of these altrnte symbols: (*:<@BDEFGHIJTW_egptw{
>> Digis if symbol is #&I <== notice this includes HF and Igates too
>
>My experience in Europe is that detection of mobility based on symbols
>doesn't work very well. What works very well is the way Xastir uses: if it
>moves it is mobile!
I rejected this concept because MANY mobiles either enroute, or involved
in activities or stopped at a traffic light, or for whatever purpose may
have 0 speed when their posit goes out. Yet they are in every sense of
the word, MOBILE. What you have defined is "MOVING" stations, not MOBILE
stations.
I would ask that Xastir and anyone else that "selects" only on
velocity, NOT CALL THAT MOBILE. Call it MOVING.
APRSdos (and others) that may show moving stations in a different color,
or with a colored background dot, or are dead reckoned and with a Velocity
leader, dont need a JUST-MOVING option, because they are all so visible in
the first place.
>This also keeps "static" mobiles out of sight and is
>compatible with any future symbol for mobiles.
Again, you have described a MOVING selector and it should not be called
a MOBILE selector, because it isnt, and will only lead to cross-platform
confusion.
>I wished PocketAPRS implemented this the same way.
I dont know what he used, but I wish we could all agree on what are the
"mobile" ICONS for the purpose of such a selection, and all implement it
the same way. That is why I furnished my "MOBILE" ICONS list above.
I have no objections to your MOVING selector, but dont call it MOBILE...
>Anyway, if it moves it must be mobile, this looks rather fail-safe to me.
But if its MOBILE it may not be moving. I would avoid this ambiguity.
In emergency work, it is important to know where your mobiles are, and
who is MOBILE capable.
>The only problems I see are:
>1) When somebody is sending slightly different positions (for example
>base-91 compressed posits combined with an occasional plain posit for those
>clients that do not understand compressed posits).
APRSdos has always solved this problem with a default 100 yard filter on
all incoming posits. If a new posit comes in that is within +/- .01 in
Latitude or Longitude it is accepted, but it does NOT trigger any
"new-posit", or "he moved" alarms..., nor add it to the log file. The
user can turn this off on a single session if he wants, but it defaults to
on so that the LOG files dont fill up with wantdering GPS's...
>2) Wandering GPS data which moves arround a fixed point. >
>Both can be solved by allowing a small margin (e.g. 100 meters should be
>rather safe) arround a posit.
OOPS, sorry, I see you already thought of that. Thanks. Yes, that was
essential to the fundamentals of APRS, since back then, with Selective
Availability always ON, then all GPS positions wandered like that..
de WB4APR@amsat.org, Bob
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
