OpenBCM V1.07b12 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
ZL3AI  > APRDIG   13.05.07 05:44l 164 Lines 5899 Bytes #999 (0) @ WW
BID : 10156-ZL3AI
Read: GUEST
Subj: [APRSSIG] Vol 35 #3, 2/2
Path: DB0FHN<DB0FOR<DB0MRW<DK0WUE<F4BWT<IW2OAZ<ZL2BAU
Sent: 070513/0340Z @:ZL2BAU.#79.NZL.OC #:47564 [Waimate] $:10156-ZL3AI
From: ZL3AI@ZL2BAU.#79.NZL.OC
To  : APRDIG@WW

Message: 8
Date: Wed, 2 May 2007 18:26:28 -0700
From: "Keith VE7GDH" <ve7gdh_at_rac.ca>
Subject: RE: [aprssig] Objects on APRS

Jim N7VR wrote...

>To ask an Igate Owner to constantly watch and update the gateway
>to consistently put these on RF is adding to his work load. The work
>load should be from the person or station generating the Object.

I'm not sure if I'm mis-understanding you here. Yes, the IGate operator must 
intentionally gate the object (because he wanted to or because the IRLP node 
operator asked him to) but once the IGate operator has added the object name 
to his IGate settings, he doesn't have to touch it again. For the object to 
exist, the IRLP node operator must install the APRS status script.

IRLP Node operators can see aprs_status-4.0.tgz at 
http://irlp.kc6hur.net/irlp_scripts.php to install the script on their node.

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

------------------------------

Message: 9
Date: Thu, 3 May 2007 07:30:17 +0200
From: Martin Henning <martin_at_easy2design.de>
Subject: Re: [aprssig] APRS in a PRIUS (fwd)

Hey Bob,

On May 2, 2007, at 7:12 AM, Michael Dirska wrote:

[got this forwarded, needed to subscribe first :)]

>Robert Bruninga wrote:
>>Since APRS is for cars, and cars nowadays contain OBD telemetry,
>>I wonder if anyone has good experience with the Onboard
>>Diagnostics tools available for a Laptop?
>>
>>IE, plug in my laptop and find out all that is going on inside a
>>Prius?
>>
>>Thanks.
>>Bob

Did you find these?

Someone testing software on his Prius: http://alflash.com.ua/prius05.htm
And if you have more time - the fullblown CAN232 dignostic suite in  
DIY-style: http://www.vassfamily.net/ToyotaPrius/CAN/cindex.html#HW

Have fun,

..martin

P.S.: Hiya all, it's my first post here :)

--
Martin Henning
martin_at_easy2design.de
http://log.tigerbus.de

------------------------------

Message: 10
Date: Thu, 3 May 2007 12:57:02 -0400
From: "Robert Bruninga" <bruninga_at_usna.edu>
Subject: RE: [aprssig] Objects on APRS

>The best place for the object is local RF.  An IRLP,
>Repeater, Echo Link, in Billings, MT are only good
>to the local APRS travelers n RF in the local community.
>Therefore they need to be sent out on local RF. If
>they appear on the APRS-IS it should be from being
>received from RF.

Agree completely.  But requiring 10,000 non-APRS sysops and owners of ILRP
and ECHOlink nodes to invest in a separate 144.39 TX and a TNC to generate
the object is never going to happen (though a few did).

When solved this by asking the IRLP and ECHOlink systems to simply generate
the objects onto the APRS-IS so that the objects at least existed from a
reliable source, and then they can piggyback on the existing TNC and
existing TX of the local Igate.  Done...

>To ask an Igate Owner to constantly watch and update the
>gateway to consistently put these on RF is adding to his
>work load.  The work load should be from the person or
>station generating the Object.

To provide a local RF service, the Igate should not just be a
plug-and-forget.  The SYSOP should be kept informed of the local RF domain
and the local IRLP and ECHOlink sysops should request that the local Igate
have these two local objects passed-to-rf.

I see these local resource sysops working and talking together so that the
APRS map display in each area does represent to the local community, what
the leaders in the local community feel are important RF assets.

The burden is not just on the Igate (though he has to make the entry to
activate the object).  The other observers need to keep these sysops
informed of any major change in the local assets that would need to be
reflected in the Igate settings.

>This is true of Hospital, EOC, Police, Fire and other objects.

No, these are not RF assets, and they do not have changing STATUS that is
of immediate need to local RF operators.  None of these objects are
initiated on the APRS-IS anyway.  Anyone in the area that activates an EOC
or a Firestation forsome immediate event, is responsbile himself for
placing it on the map.

The only APRS-IS initiated objects to my knolwedge that fit the category of
needing to be added to the local Igate pass-to-RF list are the desired
local IRLP and ECHOlink nodes.

>I would not like to receive a call about all the objects I am gating to RF.

I agree completely.  No one should be transmitting -routine-, inanimate,
non-RF objects to RF.  I see far too much of that and it is a waste of
resources.  Especailly, since built into APRS was the feature to QUERY for
EOC's, Query for hospitals, or anything else so that they couild be
tranmistted on demand, but no one wants to see these objects all the time.
But we are only asking for two local objects in the coverage area of any
given Igate.  That is, the active IRLP and ECHOlink objects.

>It makes better sense for the local stations to generate the RF information.

Better sense, true, but will never happen.  That's 10,000 TNC's and 10,000
radios someone has to buy and it simply wont happen.

I think we may be talking apples and oranges.  Here are my key points:

1) No one likes to see routine objects of no immediate RF value

2) We are never going to get local IRLP and ECHO nodes to generate their
own

3) It is so simple to generate them in real time on the APRS-IS straight
from the IRLP and ECHO central database so that the object reflects the
real-time status of the node.

4) All we are expecting is for the Igate operator to be knowledgible of the
RF assets in his community and to assist the local are in putting these out
by adding them to his pass-to-RF list.

Hope that helps
Bob, WB4APR

------------------------------

aprssig mailing list
aprssig_at_lists.tapr.org
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig

End of aprssig Digest, Vol 35, Issue 3



Read previous mail | Read next mail


 18.05.2024 19:54:47lGo back Go up