On Aug 24, 2007, at 4:56 PM, Curt, WE7U wrote:
On Wed, 22 Aug 2007, Craig Anderson wrote:
Or is it that Xastir marks a site as being from the TNC
because it is first seen by the TNC?
I believe if it is heard by the TNC at all (doesn't have to be
first?) the flag gets set. Xastir treats
Ooops. I may have an explanation for my problem.
When I set up my 100 mile filter on the socal.aprs2.net
INET interface, I used rounded LAT/LON numbers,
which put the center of my filter 20 to 30 miles away
from me. The stations I was missing were within 100
miles of me but maybe not the center
What we're looking at is dynamically creating the KMLs that look to the
APRS-IS, connect for receive-only and snag the data directly, I think.
There may also be a path to have Xastir spawn a client process to fire
off GoogleEarth and act as the server for the KML seeks. I've not
thought
GraphicsMagickis the same rev level that I use on the T42 (Fedora 7)
ImageMagick 6.3.2 also.
Sounds like your pkg of GM/IM was not compiled with the support because
mine is working just fine.
73 from 807,
Richard, N6NKO
Andrew Rich wrote:
GraphicsMagick-1.1.7-24
ImageMagick-6.3.0.0-16
James Ewen wrote:
On 8/24/07, Steve Friis [EMAIL PROTECTED] wrote:
Way cool. Since the RF pollution is so high here, I am trying to lower
it some to that low power stations can be heard, or at least stand a
chance.
Steve,
Another incorrect supposition. Adding i-gating to your
Most likely
I used YAST and SUSE 10.2
Maybe I can work on an XASTIR software repositry and install notes ?
Andrew Rich VK4TEC
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
http://www.tech-software.net
-Original
My first thoughts on implementation for this would be some kind of scraping
method maybe? I certainly wouldn't want to abuse Google's servers, but what
about passing static strings with the positional as a standard http request
and then somehow getting that data to display inside Xastir?
There
Looking at the DB0ANF page I realized that the report is named APRS
Stations using USAM as their Digi / Uplink - this appears to mean
that the report shows stations that were either digi'ed OR iGated by
a particular station. So it appears that I was in error to believe
that DB0ANF reports
Hi.
Running openSuSE 10.2, and Xastir 1.8.5
Is there a more new version for SuSE ?
--
Med venlig hilsen / Best regards
Erik Jakobsen OZ4KK
[EMAIL PROTECTED]
openSuSE 10.2 (i586)
___
Xastir mailing list
Xastir@xastir.org
1.9.1 if you compile from source
--- Erik Jakobsen [EMAIL PROTECTED] wrote:
Hi.
Running openSuSE 10.2, and Xastir 1.8.5
Is there a more new version for SuSE ?
--
Med venlig hilsen / Best regards
Erik Jakobsen OZ4KK
[EMAIL PROTECTED]
openSuSE 10.2 (i586)
On 8/25/07, Steve Friis [EMAIL PROTECTED] wrote:
The hope is that the El Paso, Local an URFMS digi's will lower the hops
they retransmit.
See my comment above. I was not thinking that supposition, but the way I
worded my first comment I can see how you would think that is what I meant.
At 03:20 PM 8/25/2007, James Ewen wrote:
It's really hard to make good comments on a system that you can only
observe via the APRS-IS, without any knowledge of the local terrain.
Wow, it's GREAT to see somebody finally acknowledge
this! I've been trying to tell people that for maybe
On Sat, 2007-08-25 at 06:47 -0500, Gerry Creager wrote:
Near as I could tell, it's not on Google's horizon but they're amenable
to almost any non-terrorist use of Google Maps||Earth.
I've looked at this a couple of times lately but I'm pure outta cycles
and interrupt processing right now.
What would you want to scrape? I'd make the data available as a network
option from within Xastir... and I might also consider standing up an
APRS KML data server. Keep up the ideas. We might kindle something
here after all!
gerry
Stephen - K1LNX wrote:
My first thoughts on implementation
The first is a hold-harmless: They don't want to be responsible for
stupid user tricks when you use Google Earth in a manner they can't
prove is safe.
The second is to allow them and their license-holders the right and
opportunity to see hard-copy output in large volumes.
I've discussed the
On 8/25/07, Alex Carver [EMAIL PROTECTED] wrote:
In that same train of thought, it would be nice if the
APRS-IS could show the duplicate packets instead of
discarding them. Then you possibly _could_ get a
better understanding of the RF network by watching how
a packet propagates and
--- Matt Werner [EMAIL PROTECTED] wrote:
On 8/25/07, Alex Carver [EMAIL PROTECTED] wrote:
In that same train of thought, it would be nice if
the
APRS-IS could show the duplicate packets instead
of
discarding them. Then you possibly _could_ get a
better understanding of the RF
On 8/25/07, Alex Carver [EMAIL PROTECTED] wrote:
In that same train of thought, it would be nice if the
APRS-IS could show the duplicate packets instead of
discarding them. Then you possibly _could_ get a
better understanding of the RF network by watching how
a packet propagates and
Hi Alex -
I don't think so. Once a server receives the packet it will not send
on the same packet if it hears it come in from a different igate or
server. Imagine this:
One server (we'll call it A) has 5 different igates connected to it
from one area and another server (we'll call it B) has 5
I've discussed the first with them directly. They're intrigued by Xastir
(and APRS in general) and see it not as a violation. Even if used in your
car.
All the more reason to spawn development!
What would you want to scrape? I'd make the data available as a network
option from within
Earl Needham wrote:
At 03:20 PM 8/25/2007, James Ewen wrote:
It's really hard to make good comments on a system that you can only
observe via the APRS-IS, without any knowledge of the local terrain.
Wow, it's GREAT to see somebody finally acknowledge this!
I've been trying to tell
My apologies. I didn't realize random Google employees trump legal
documents their high paid lawyers so tediously put together.
That's just me, though. YMMV. ;-)
On Sat, 2007-08-25 at 19:00 -0500, Gerry Creager wrote:
The first is a hold-harmless: They don't want to be responsible for
22 matches
Mail list logo
