Tuesday, July 30, 2002
to NWAPRS
---
Here's why having a WIDE,WIDE2-2 path instead of WIDE3-3
is handy. The URL's below are JavAPRS displays of
stations heard by the respective digi's and the range circle
as given by the digi:
SEA:
http://www.jnos.org/cgi-bin/ja?datafile2=tnc/sea.tnc&port=10156&drawCircles=true
SEATAC:
http://www.jnos.org/cgi-bin/ja?datafile2=tnc/sea.tnc&port=10156&drawCircles=true
SOMTN:
http://www.jnos.org/cgi-bin/ja?datafile2=tnc/sea.tnc&port=10156&drawCircles=true
A "U" command on the SOMTN display is needed to zoom UP and see the
complete list of stations.
(Ignore the error about opening the data stream. I'm passing in a
non-valid port so it doesn't clutter the screen with new stations.)
I'll have this generic for any digi call in the near future.
---
Here's why having a WIDE,WIDE2-2 path instead of WIDE3-3
is handy. The URL's below are JavAPRS displays of
stations heard by the respective digi's and the range circle
as given by the digi:
SEA:
http://www.jnos.org/cgi-bin/ja?datafile2=tnc/sea.tnc&port=10156&drawCircles=true
SEATAC:
http://www.jnos.org/cgi-bin/ja?datafile2=tnc/sea.tnc&port=10156&drawCircles=true
SOMTN:
http://www.jnos.org/cgi-bin/ja?datafile2=tnc/sea.tnc&port=10156&drawCircles=true
A "U" command on the SOMTN display is needed to zoom UP and see the
complete list of stations.
(Ignore the error about opening the data stream. I'm passing in a
non-valid port so it doesn't clutter the screen with new stations.)
I'll have this generic for any digi call in the near future.
Sunday, July 28, 2002
to NWAPRS
---
Several folks made changes after my note a week ago
and from what I see on the raw port, 14580, of jnos.org -
it's made a significant difference in the information available
from the flow of packets.
There's still a few stations with no leading digi alias to allow
digi call sign substitution.
If your outgoing path is:
WIDE3-3
please change it to
WIDE,WIDE2-2
The wide digi's will put their call in place of the first WIDE so we can
see by "vicinity" tracking who picked up the packet on the first hop.
Here's an example of how it works:
KD7NM-9>GPSMV,RELAY,WIDE3-3:$GPRMC,164159,A,...
KD7NM-9>GPSMV,K7NWS-10*,WIDE3-3:$GPRMC,164159,A,...
KD7NM-9>GPSMV,K7NWS-10*,WIDE3-2:$GPRMC,164159,A,...
By simply looking at this we see that K7NWS-10 picked up KD7NM-9
and that puts Bob in the general Seattle area. I.E. In the vicinity of Seattle.
An added benefit to this vicinity tracking is that it shows the "range" of a digi.
I plan to have a web page running by the end of the week that will plot the
stations heard - by digi. Then we'll know just how close those PHG circles
really are.
---
Second tweak.
It's amazing the number of folks still using WIDE4 and WIDE5 in their paths. Given
the number of multiple copies of packets that are being seen, this is seldom
needed.
Speaking of multiple copies of packets, even at WIDE3-3, I'd suggest that
we could safely move towards a standard of WIDE2-2. Folks now
that want to be a bit conservative and have no pressing need to be seen
in Utah could replace their WIDE3-3 with WIDE2-2 and save a few extra
packets on the system.
A WIDE3-3 packet with a path history of: >AP...,WIDE3*: is one that
wouldn't be seen if the WIDE3-3 was changed to WIDE2-2. In my casual
observations, I've seen exactly ONE such packet without other packets from
the same transmission proceeding it. So, from where I sit, a change to WIDE2-2
from WIDE3-3 would have essentially no affect on the data received - it would
just reduce the number of packets on the channel.
---
73,
Bill - WA7NWP
---
Several folks made changes after my note a week ago
and from what I see on the raw port, 14580, of jnos.org -
it's made a significant difference in the information available
from the flow of packets.
There's still a few stations with no leading digi alias to allow
digi call sign substitution.
If your outgoing path is:
WIDE3-3
please change it to
WIDE,WIDE2-2
The wide digi's will put their call in place of the first WIDE so we can
see by "vicinity" tracking who picked up the packet on the first hop.
Here's an example of how it works:
KD7NM-9>GPSMV,RELAY,WIDE3-3:$GPRMC,164159,A,...
KD7NM-9>GPSMV,K7NWS-10*,WIDE3-3:$GPRMC,164159,A,...
KD7NM-9>GPSMV,K7NWS-10*,WIDE3-2:$GPRMC,164159,A,...
By simply looking at this we see that K7NWS-10 picked up KD7NM-9
and that puts Bob in the general Seattle area. I.E. In the vicinity of Seattle.
An added benefit to this vicinity tracking is that it shows the "range" of a digi.
I plan to have a web page running by the end of the week that will plot the
stations heard - by digi. Then we'll know just how close those PHG circles
really are.
---
Second tweak.
It's amazing the number of folks still using WIDE4 and WIDE5 in their paths. Given
the number of multiple copies of packets that are being seen, this is seldom
needed.
Speaking of multiple copies of packets, even at WIDE3-3, I'd suggest that
we could safely move towards a standard of WIDE2-2. Folks now
that want to be a bit conservative and have no pressing need to be seen
in Utah could replace their WIDE3-3 with WIDE2-2 and save a few extra
packets on the system.
A WIDE3-3 packet with a path history of: >AP...
wouldn't be seen if the WIDE3-3 was changed to WIDE2-2. In my casual
observations, I've seen exactly ONE such packet without other packets from
the same transmission proceeding it. So, from where I sit, a change to WIDE2-2
from WIDE3-3 would have essentially no affect on the data received - it would
just reduce the number of packets on the channel.
---
73,
Bill - WA7NWP
Friday, July 26, 2002
to Wetnet
---
Steve Stroh and I had a fascinating adventure of NetStumbler
driving yesterday afternoon. Several "new to us" techniques were
explored and implemented.
GPS with NetStumbler.
Wi-FI Orinoco Card with external mag mount antenna.
Saving NetStumbler Data.
Charging the laptop while running in the vehicle.
Simply running NetStumbler while mobile was new to me.
It was an interesting, fun and educational experience. An APRS map
of the summary data is available via JavAPRS - ALT-CLICK on the
cluster of red dots new my home a couple times to zoom in on our
area of travel.
http://www.jnos.org/cgi-bin/ja?stum1.pos&expedia
Some observations.
Lots of folks are putting up Wi-Fi nodes. Maybe 1 in 5 are using WEP
encryption for security.
The range of a standard home Access Point (AP) is roughly from the
house to the street - if that. A commercial high power AP extends that
to hundreds of feet - still very limited.
Using an IP number fetched from Steve's DHCP server, I was able to
access the Internet via two additional Access Points. Nothing had to
be changed with the running system. The ping session came alive on
its own.
Now for the biggest observation. It's just plain frustrating to be sitting at a coffee
shop with the computer open and running, with an Wi-Fi card installed, and not
having any Internet access. This reinforces and even more strongly validates
our jeep-gate concept of having the local mobile server in the vehicle accessed
by the remote user.
The weak point so far in our (WETNET) concept is getting Internet (even if slow just for
Email and Instant Messaging) to the mobile hub. As it sits we have three 9k6 hubs
in the region, one running at full power. These three hubs cover a reasonable
portion of the region. However they are all on different frequencies which
limits the hardware available to talk to all of them. (Maxon radios...)
Suppose that in addition to using these disjoint "high performance" systems we
added one single 9k6 frequency on 440 MHz. (220 MHz would be a possibility
but the availability of equipment is an issue.) Everybody with DSL or even
dial up Internet access would be an Amateur Access Point (AAP). We'd take
a performance hit over the digital repeaters, but it would make it far easier to
cover the region.
Even dump digi's could be used to fill in areas if necessary.
Another benefit would be the possibility of point-to-point operation with out the
need of the repeater. When locked to a repeater split - you can't communicate
with a neighbor when the repeater is down regardless how good your direct
path is.
This plan doesn't eliminate the need for the packet repeaters. Far from it
as then they'd be the Medium Area Networks that could be used to tie the
simplex cells together.
Mobile gates desiring better performance and willing to make the investment could
have multi channel systems that use the repeaters when possible and dropped
back to the simplex channel if necessary.
Taking this a step further, we could set up a similar simplex single frequency
network running 1200 baud on two meters. Again the performance hit would
be compensated by the ease of use and extended coverage.
Let the fireworks begin...
Bill, WA7NWP
---
Steve Stroh and I had a fascinating adventure of NetStumbler
driving yesterday afternoon. Several "new to us" techniques were
explored and implemented.
GPS with NetStumbler.
Wi-FI Orinoco Card with external mag mount antenna.
Saving NetStumbler Data.
Charging the laptop while running in the vehicle.
Simply running NetStumbler while mobile was new to me.
It was an interesting, fun and educational experience. An APRS map
of the summary data is available via JavAPRS - ALT-CLICK on the
cluster of red dots new my home a couple times to zoom in on our
area of travel.
http://www.jnos.org/cgi-bin/ja?stum1.pos&expedia
Some observations.
Lots of folks are putting up Wi-Fi nodes. Maybe 1 in 5 are using WEP
encryption for security.
The range of a standard home Access Point (AP) is roughly from the
house to the street - if that. A commercial high power AP extends that
to hundreds of feet - still very limited.
Using an IP number fetched from Steve's DHCP server, I was able to
access the Internet via two additional Access Points. Nothing had to
be changed with the running system. The ping session came alive on
its own.
Now for the biggest observation. It's just plain frustrating to be sitting at a coffee
shop with the computer open and running, with an Wi-Fi card installed, and not
having any Internet access. This reinforces and even more strongly validates
our jeep-gate concept of having the local mobile server in the vehicle accessed
by the remote user.
The weak point so far in our (WETNET) concept is getting Internet (even if slow just for
Email and Instant Messaging) to the mobile hub. As it sits we have three 9k6 hubs
in the region, one running at full power. These three hubs cover a reasonable
portion of the region. However they are all on different frequencies which
limits the hardware available to talk to all of them. (Maxon radios...)
Suppose that in addition to using these disjoint "high performance" systems we
added one single 9k6 frequency on 440 MHz. (220 MHz would be a possibility
but the availability of equipment is an issue.) Everybody with DSL or even
dial up Internet access would be an Amateur Access Point (AAP). We'd take
a performance hit over the digital repeaters, but it would make it far easier to
cover the region.
Even dump digi's could be used to fill in areas if necessary.
Another benefit would be the possibility of point-to-point operation with out the
need of the repeater. When locked to a repeater split - you can't communicate
with a neighbor when the repeater is down regardless how good your direct
path is.
This plan doesn't eliminate the need for the packet repeaters. Far from it
as then they'd be the Medium Area Networks that could be used to tie the
simplex cells together.
Mobile gates desiring better performance and willing to make the investment could
have multi channel systems that use the repeaters when possible and dropped
back to the simplex channel if necessary.
Taking this a step further, we could set up a similar simplex single frequency
network running 1200 baud on two meters. Again the performance hit would
be compensated by the ease of use and extended coverage.
Let the fireworks begin...
Bill, WA7NWP
Wednesday, July 24, 2002
Date: Wed, 24 Jul 2002 10:12:35 -0700
To: "TAPR APRS Special Interest Group"
Subject: [aprssig] Re: APRS on your cell phone! -- New ATT Wireless service
> >Cell phones allow position location in buildings, tunnels, etc.
>
>Actually cell phone technology, as ATT is pushing, only allows tracking to the
>location of the cell tower the call is being recieved on. In a rural area's
>this could be off by miles.
AKA Vicinity tracking in APRS.
I wonder if some of the Cell Sites are in ID mode while others are NOID...
Sorry - I couldn't resist...
Bill, WA7NWP
To: "TAPR APRS Special Interest Group"
Subject: [aprssig] Re: APRS on your cell phone! -- New ATT Wireless service
> >Cell phones allow position location in buildings, tunnels, etc.
>
>Actually cell phone technology, as ATT is pushing, only allows tracking to the
>location of the cell tower the call is being recieved on. In a rural area's
>this could be off by miles.
AKA Vicinity tracking in APRS.
I wonder if some of the Cell Sites are in ID mode while others are NOID...
Sorry - I couldn't resist...
Bill, WA7NWP
Tuesday, July 23, 2002
to aprssig
---
At 04:17 PM 7/23/02 -0400, Michael J. Wolthuis wrote:
I heard information that an addon exists for APRS+SA to make it function
as APRSData does for sending objects to the local RF. I am currently
running APRSData, but would like to try running this with APRS+SA, any
information on such a program would be great! I tried writing a few
people off this list with no responses.
Fortunately a WikiWiki makes it Quick-Quick to import documentation from
the old html format.
http://www.jnos.org/cgi-bin/moin.cgi/Wa7nwpPacketTool
73,
Bill - WA7NWP
---
At 04:17 PM 7/23/02 -0400, Michael J. Wolthuis wrote:
I heard information that an addon exists for APRS+SA to make it function
as APRSData does for sending objects to the local RF. I am currently
running APRSData, but would like to try running this with APRS+SA, any
information on such a program would be great! I tried writing a few
people off this list with no responses.
Fortunately a WikiWiki makes it Quick-Quick to import documentation from
the old html format.
http://www.jnos.org/cgi-bin/moin.cgi/Wa7nwpPacketTool
73,
Bill - WA7NWP
to aprssig
---
At 05:55 PM 7/22/02 -0500, Dave Kaplan wrote:
>Is there anyone on the SIG using KIPSS wth APRS+SA? I need somew help getting it running.
Works great here...
My configuration is:
OPEN: Com1:9600,n,8,1
KISS ON: INT KISSRESET
Click "ON" - then Click "KISS ON"
You might have to change the KISS ON string. I've found it sometimes needs
a click on "KISS ON" even if the TNC is already in KISS mode. That doesn't
hurt anything.
Another trick is to make sure the port is OFF and not already being used
on the main Setup display screen.
Bill, WA7NWP
---
At 05:55 PM 7/22/02 -0500, Dave Kaplan wrote:
>Is there anyone on the SIG using KIPSS wth APRS+SA? I need somew help getting it running.
Works great here...
My configuration is:
OPEN: Com1:9600,n,8,1
KISS ON: INT KISS
Click "ON" - then Click "KISS ON"
You might have to change the KISS ON string. I've found it sometimes needs
a click on "KISS ON" even if the TNC is already in KISS mode. That doesn't
hurt anything.
Another trick is to make sure the port is OFF and not already being used
on the main Setup display screen.
Bill, WA7NWP
Friday, July 19, 2002
To gateways list
---
At 05:29 PM 7/16/02 -0700, Brian Kantor wrote:
Would it not be a good idea to get the network fully connected in the first
place? Then we can worry about redundancy.
- Brian
---
Redundant paths would be a step towards improving the network
connectivity. Right now, if any gateway goes away for any reason, everybody
downstream from it is no longer connected. If there was some trick
to include backup routes packets would keep flowing.
In the Western Washington area, we have three or four registered gateways
with overlapping coverage. There are three or four more systems capable
of functioning as backup gateways. Yet if the official registered machines
go down or lose their Internet connection for any reason, the subnet(s) they
serve is disconnected and it would take days to update the official routing table.
Of course this isn't a big thing. The existing system is very impressive and
I love to dazzle the Wi-Fi freenet folks with tales of the ampr.org worldwide
vlan and it's 650+ systems. Still, backup routing would be an opportunity
to make the system better and more robust.
Bill
---
At 05:29 PM 7/16/02 -0700, Brian Kantor wrote:
Would it not be a good idea to get the network fully connected in the first
place? Then we can worry about redundancy.
- Brian
---
Redundant paths would be a step towards improving the network
connectivity. Right now, if any gateway goes away for any reason, everybody
downstream from it is no longer connected. If there was some trick
to include backup routes packets would keep flowing.
In the Western Washington area, we have three or four registered gateways
with overlapping coverage. There are three or four more systems capable
of functioning as backup gateways. Yet if the official registered machines
go down or lose their Internet connection for any reason, the subnet(s) they
serve is disconnected and it would take days to update the official routing table.
Of course this isn't a big thing. The existing system is very impressive and
I love to dazzle the Wi-Fi freenet folks with tales of the ampr.org worldwide
vlan and it's 650+ systems. Still, backup routing would be an opportunity
to make the system better and more robust.
Bill
Thursday, July 18, 2002
Northwest Automatic Position Reporting System SIG Mailing List
---
For the past few days I've been watching the raw feed of packets as
heard by my system. (jnos.org port 14580) The difference between
this and the traffic flow after duplicates have been removed is very
interesting..
Here's a couple suggestions/comments.
I bet we could, for the most part, go from RELAY,WIDE3-3 to RELAY,WIDE2-2
with little noticeable affect.
I've noticed a few stations using a path of plain WIDE3-3 or WIDE2-2. That's
what I used to do my self. It was just recently that I finally realized (DOH) that
this breaks the vicinity tracking feature. By "vicinity tracking" I'm referring to
how the first node hearing the packet replaces the generic "RELAY" or "WIDE"
path with their node identifier. Thus you know "about where" the node
was that picket up the first packet. Bottom line -
WIDE3-3 -> WIDE,WIDE2-2
WIDE2-2 -> WIDE,WIDE1-1
I believe the WIDE1-1 is required here so you don't get another "wide" callsign
substitution.
There are still some stations running WinAprs 2.4.6. This version of WinAPRS
has a Mic-E conversion bug. It should NEVER be used for an Igate and I'd
guess my even should bad locations locally. WinAPRS 2.4.6 should be upgraded
with a newer version!
There are some stations using WIDE5 and WIDE4 paths. That's a lot of extra
packets that aren't needed.
Finally, I think (and I'm certainly not positive about this) there are two nodes, one
south of the border and one in VE7 land are running in ID mode where they replace
the first callsign with their own. This breaks the vicinity tracking and is going to make
some future programs display erroneous information.
Back to watching the packets flow..
73,
Bill - WA7NWP
---
For the past few days I've been watching the raw feed of packets as
heard by my system. (jnos.org port 14580) The difference between
this and the traffic flow after duplicates have been removed is very
interesting..
Here's a couple suggestions/comments.
I bet we could, for the most part, go from RELAY,WIDE3-3 to RELAY,WIDE2-2
with little noticeable affect.
I've noticed a few stations using a path of plain WIDE3-3 or WIDE2-2. That's
what I used to do my self. It was just recently that I finally realized (DOH) that
this breaks the vicinity tracking feature. By "vicinity tracking" I'm referring to
how the first node hearing the packet replaces the generic "RELAY" or "WIDE"
path with their node identifier. Thus you know "about where" the node
was that picket up the first packet. Bottom line -
WIDE3-3 -> WIDE,WIDE2-2
WIDE2-2 -> WIDE,WIDE1-1
I believe the WIDE1-1 is required here so you don't get another "wide" callsign
substitution.
There are still some stations running WinAprs 2.4.6. This version of WinAPRS
has a Mic-E conversion bug. It should NEVER be used for an Igate and I'd
guess my even should bad locations locally. WinAPRS 2.4.6 should be upgraded
with a newer version!
There are some stations using WIDE5 and WIDE4 paths. That's a lot of extra
packets that aren't needed.
Finally, I think (and I'm certainly not positive about this) there are two nodes, one
south of the border and one in VE7 land are running in ID mode where they replace
the first callsign with their own. This breaks the vicinity tracking and is going to make
some future programs display erroneous information.
Back to watching the packets flow..
73,
Bill - WA7NWP
to SeattleWireless
---
At 05:22 AM 7/18/02 -0400, Evan M. Webb wrote:
Hello everyone,
i'm actually currently organizing the system not around the map, but
around the data that generates those maps.
---
That's the key. We have multiple mapping systems available - the
missing ingredient is the data. The original XML data file I played with
worked fine except there was no way to tell the difference between nodes
proposed and running. Also there was no scheme to show linking
between nodes.
Tom Marshall posted here last April with a new database and mapping
program that added the needed data fields. (Node type, node status, node ID, etc)
It would also be very nice to have web based data entry. I believe the newer
versions of MoinMoin will handle XML data - haven't had time to try that here yet.
Bill
---
At 05:22 AM 7/18/02 -0400, Evan M. Webb wrote:
Hello everyone,
i'm actually currently organizing the system not around the map, but
around the data that generates those maps.
---
That's the key. We have multiple mapping systems available - the
missing ingredient is the data. The original XML data file I played with
worked fine except there was no way to tell the difference between nodes
proposed and running. Also there was no scheme to show linking
between nodes.
Tom Marshall posted here last April with a new database and mapping
program that added the needed data fields. (Node type, node status, node ID, etc)
It would also be very nice to have web based data entry. I believe the newer
versions of MoinMoin will handle XML data - haven't had time to try that here yet.
Bill
Tuesday, July 16, 2002
to SEATCP
---
This stuff really works...
As you know, I've been on this kick to learn more about (real) Internet networking
technology by using as much of it as possible with the Linux systems and our
Wetnet network.
Yesterday we had a good example of how the Email caching works. Tim's computer
lost its mind and couldn't be reached. (He says it's my fault but I don't think I can
take the credit for that one.) My system is set to handle Tim's as a Relay-Domain and is
in the routing tables as a lower priority (higher number) MX record. So while Tim's
system was out having a beer somewhere, my system dutifully accepted incoming
messages and tried to deliver then on scheduled intervals. Several hours later, the
wayward system came back on line. Shortly afterwards, the cached messages were
delivered.
I'm happy to report - no SPAM was lost.
73,
Bill - WA7NWP
---
This stuff really works...
As you know, I've been on this kick to learn more about (real) Internet networking
technology by using as much of it as possible with the Linux systems and our
Wetnet network.
Yesterday we had a good example of how the Email caching works. Tim's computer
lost its mind and couldn't be reached. (He says it's my fault but I don't think I can
take the credit for that one.) My system is set to handle Tim's as a Relay-Domain and is
in the routing tables as a lower priority (higher number) MX record. So while Tim's
system was out having a beer somewhere, my system dutifully accepted incoming
messages and tried to deliver then on scheduled intervals. Several hours later, the
wayward system came back on line. Shortly afterwards, the cached messages were
delivered.
I'm happy to report - no SPAM was lost.
73,
Bill - WA7NWP
Friday, July 12, 2002
to APRSSIG
---
>As I stated before, many places do not permit
>the discharge of firearms, pellet guns, longbows and
>crossbows.
Nor sling shots... They're illegal here in the
Republic of Redmond...
Bill, WA7NWP
>As in New Jersey. How do you guys string antennas for field day?
>
> http://www.antennex.com/hws/ws0502/seall.html
Nice safe spud guns... A little right guard never
hurt anybody...
---
>As I stated before, many places do not permit
>the discharge of firearms, pellet guns, longbows and
>crossbows.
Nor sling shots... They're illegal here in the
Republic of Redmond...
Bill, WA7NWP
>As in New Jersey. How do you guys string antennas for field day?
>
> http://www.antennex.com/hws/ws0502/seall.html
Nice safe spud guns...
hurt anybody...
Date: Fri, 12 Jul 2002 13:39:59 -0700
To: "TAPR Hot Technology APRS"
Subject: [htaprs] Re: D7 Replacement w/ Built-in GPS Receiver/Bluetooth
At 06:54 AM 3/28/02 -0600, Jon Ogden wrote:
>The good news is that there is possibly coming some relief to a small extent
>but from an odd angle. The new direct broadcast satellite radio servcies of
>XM Radio and Sirius Radio broadcast right below the 2.4 GHz band. Sirius is
>very concerned that all of the 2.4 GHz devices may be spewing crap into
>their part of the band and hence may interfere with people's reception of
>their service. They have petitioned the FCC to change the rules for
>unlicensed 2.4 GHz devices to reduce the spurious emissions levels as well
>as overall power levels. ...
>
>The good news for hams is that for one, we are licensed and should not be
>affected by the new rules. Secondly, any emissions reductions in any way
>shape or form of 2.4 GHz products is a big benefit IMO. What's likely is
>the ruling will drive manufacturers higher in frequency to the 5.3 GHz (I
>think that's where it is) band where we don't have any issues with them!
>Jon
>NA9D
There is good news, but not quiet what Jon was referring to. The motions by
Sirius and XM Radio have been negated. An article from the Sifry Blog
is copied below.
The explosion in 2.4GHz unlicensed radio communications is the best thing that's happened
to the art in years.
Now if only they'd release a Wi-Fi GPS on the market...
73,
Bill - WA7NWP
--- http://www.sifry.com/alerts/archives/2002_06.html ---
Sirius has withdrawn their FCC petition! According to Carl R. Stevenson, Interim Chair of the IEEE 802.18 Regulatory Technical Advisory Group, Sirius has withdrawn its FCC petition regarding out of band (OOB) emissions from 2.4GHz users.
Sifry's Alerts' comments on this development:
This is good - it removes a potential issue that overshadowed the widespread adoption of wireless technologies like 802.11b. I think the FCC would have ruled against them anyway, for the following reasons:
1. They were asking for a legislative fix to the laws of physics. This Sirius request included an OOB limit of -158dbm which is 8 dbm below the thermal noise floor. In other words, the normal evaporation of water into clouds makes more noise in the 2.5GHz spectrum. Besides, other noise generators much closer to the receiver emit a much larger noise profile. The spark emitted from a spark plug is one example.
2. Significant opposition from other established industry players, including Motorola, Intersil, Intel, and others.
3. The FCC's emphasis on reducing the digital divide. The FCC was being asked to decide if it was more important to have high-end radio between cities or cheap, high bandwidth connectivity in low income neighborhoods, and I think the public interest would have won on this one.
So, count one for the good guys today! And don't rub Sirius' nose in it - they did the right thing.
Posted by dsifry at 08:41 AM
---
To: "TAPR Hot Technology APRS"
Subject: [htaprs] Re: D7 Replacement w/ Built-in GPS Receiver/Bluetooth
At 06:54 AM 3/28/02 -0600, Jon Ogden wrote:
>The good news is that there is possibly coming some relief to a small extent
>but from an odd angle. The new direct broadcast satellite radio servcies of
>XM Radio and Sirius Radio broadcast right below the 2.4 GHz band. Sirius is
>very concerned that all of the 2.4 GHz devices may be spewing crap into
>their part of the band and hence may interfere with people's reception of
>their service. They have petitioned the FCC to change the rules for
>unlicensed 2.4 GHz devices to reduce the spurious emissions levels as well
>as overall power levels. ...
>
>The good news for hams is that for one, we are licensed and should not be
>affected by the new rules. Secondly, any emissions reductions in any way
>shape or form of 2.4 GHz products is a big benefit IMO. What's likely is
>the ruling will drive manufacturers higher in frequency to the 5.3 GHz (I
>think that's where it is) band where we don't have any issues with them!
>Jon
>NA9D
There is good news, but not quiet what Jon was referring to. The motions by
Sirius and XM Radio have been negated. An article from the Sifry Blog
is copied below.
The explosion in 2.4GHz unlicensed radio communications is the best thing that's happened
to the art in years.
Now if only they'd release a Wi-Fi GPS on the market...
73,
Bill - WA7NWP
--- http://www.sifry.com/alerts/archives/2002_06.html ---
Sirius has withdrawn their FCC petition! According to Carl R. Stevenson, Interim Chair of the IEEE 802.18 Regulatory Technical Advisory Group, Sirius has withdrawn its FCC petition regarding out of band (OOB) emissions from 2.4GHz users.
Sifry's Alerts' comments on this development:
This is good - it removes a potential issue that overshadowed the widespread adoption of wireless technologies like 802.11b. I think the FCC would have ruled against them anyway, for the following reasons:
1. They were asking for a legislative fix to the laws of physics. This Sirius request included an OOB limit of -158dbm which is 8 dbm below the thermal noise floor. In other words, the normal evaporation of water into clouds makes more noise in the 2.5GHz spectrum. Besides, other noise generators much closer to the receiver emit a much larger noise profile. The spark emitted from a spark plug is one example.
2. Significant opposition from other established industry players, including Motorola, Intersil, Intel, and others.
3. The FCC's emphasis on reducing the digital divide. The FCC was being asked to decide if it was more important to have high-end radio between cities or cheap, high bandwidth connectivity in low income neighborhoods, and I think the public interest would have won on this one.
So, count one for the good guys today! And don't rub Sirius' nose in it - they did the right thing.
Posted by dsifry at 08:41 AM
---
Date: Fri, 12 Jul 2002 13:21:16 -0700
To: "TAPR Hot Technology APRS"
Subject: [htaprs] Re: TEST
At 03:10 PM 7/12/02 -0400, Bob Bruninga wrote:
>Shucks, I could write an APRStk module with no User inteface that simply
>continually writes out a file of the positions of all the satellites.,.
PTsat (was dosap) does exactly that. It uploads them to APRSPLUS if it's
running on the same machine. Control of the D7 is SMOTAPAM.
(Simple matter of time and programming and money - for a D7)
Bill, WA7NWP
To: "TAPR Hot Technology APRS"
Subject: [htaprs] Re: TEST
At 03:10 PM 7/12/02 -0400, Bob Bruninga wrote:
>Shucks, I could write an APRStk module with no User inteface that simply
>continually writes out a file of the positions of all the satellites.,.
PTsat (was dosap) does exactly that. It uploads them to APRSPLUS if it's
running on the same machine. Control of the D7 is SMOTAPAM.
(Simple matter of time and programming and money - for a D7)
Bill, WA7NWP
Wednesday, July 10, 2002
to APRSSIG
---
At 09:41 AM 7/10/02 -0500, AE5PL Lists wrote:
Looks like WXSVR has been down since about 0200z today.
We need alternate and backup Weather Servers.. The advantage of Amateur Radio
is it's a distributed resource. It would be good for a regional group
to be able to fetch and distribute their own Wx reports.
73,
Bill - WA7NWP
---
At 09:41 AM 7/10/02 -0500, AE5PL Lists wrote:
Looks like WXSVR has been down since about 0200z today.
We need alternate and backup Weather Servers.. The advantage of Amateur Radio
is it's a distributed resource. It would be good for a regional group
to be able to fetch and distribute their own Wx reports.
73,
Bill - WA7NWP
Tuesday, July 09, 2002
to APRSSIG
---
> The digined software grabs the
UI frames off these two ports and forwards them to a local loopback port in
my ax25 network layer, aprsd sits on the other end of this loopback pipe
and routes the information to the internet for me.
The thing to watch out for here is if somebody sends an APRS message to
one of the stations you've heard via the satellite. aprsd will probably think
it's a local station and respond by forwarding the message out your local
lan. I had this problem when bringing some of the HF traffic over to the
local VHF circuit. It's not a big thing but something to watch for if it
creates too much spurious local traffic.
Digi_ned needs a rule to create 3rd party headers to get around this.
73,
Bill - WA7NWP
Date: Tue, 09 Jul 2002 16:01:40 -0700
To: aprsplus@k8sn.org
From: Bill Vodall - WA7NWP
Subject: RE: [aprsplus] More on PHG circles
>While javAPRS is off topic of this SIG, it does show that there is at
>least one implementation of directivity and range circle calculations.
>
>Pete Loveall AE5PL
Brent has less control of the "circles" in APRSPLUS. It might be
possible to draw off-center or maybe even two circles. Big question
is if it's worth the programming hassle. It would be interesting to see
how many of the PHG's out there have a bearing component.
73,
Bill WA7NWP
To: aprsplus@k8sn.org
From: Bill Vodall - WA7NWP
Subject: RE: [aprsplus] More on PHG circles
>While javAPRS is off topic of this SIG, it does show that there is at
>least one implementation of directivity and range circle calculations.
>
>Pete Loveall AE5PL
Brent has less control of the "circles" in APRSPLUS. It might be
possible to draw off-center or maybe even two circles. Big question
is if it's worth the programming hassle. It would be interesting to see
how many of the PHG's out there have a bearing component.
73,
Bill WA7NWP
to Wetnet list
---
For the discussion...
>>>
SB QST @ ARL $ARLB041
ARLB041 General Communications Emergency Termination
ZCZC AG41
QST de W1AW
ARRL Bulletin 41 ARLB041
>From ARRL Headquarters
Newington CT July 8, 2002
To all radio amateurs
SB QST ARL ARLB041
ARLB041 General Communications Emergency Termination
Through mutual agreement with the president of the ARRL, Jim Haynie,
W5JBP, effective today, July 8, 2002, at 1 PM, Eastern Daylight
Savings time (1700 UTC), the Federal Communications Commission's
July 5, 2002 Declared Communications Emergency terminated.
>>>>
Fascinating. Now the FCC consults with the ARRL for their Emergency
declarations.. To think I was merely concerned with the ARRL/NFCC
relationship.
Bill, WA7NWP
Monday, July 08, 2002
to APRSSIG
---
At 05:30 PM 7/8/02 +0000, Jason Rausch wrote:
>Buy a Palm unit (Handspring or Palm) and save yourself alot of headache.
>Check out my set-ups on my site at http://www.ke4nyv.com
The HK-21 Pocket packet TNC is a terrible match for use with the Palm computers.
Color is wrong. Cables are too long. I'll be happy to make a fair deal if anybody
would like to get rid of one of these lemons. No upgrade ROM needed. While the
upgrade turns it in to a standalone APRS tracker, the basic ROM does KISS just
fine. I'm used to it and I'd hate to see anybody else have to suffer with this cute
little packet combination...
73,
Bill
PS. :-)
Sunday, July 07, 2002
to SEATCP
---
In my never ending quest for redundancy on the network, yesterdays
Milestone brunch yielded a great idea. (Thanks Eric)
Sendmail can very easily be configured to have alternate delivery
paths (that I knew) but what I didn't know was that these alternate
machines can be set to cache the incoming messages and forward
them on to the primary destination when it again becomes available.
I'm not saying this is exactly the way to do it - it's how I understand it
should be done. By presenting it here - I get it proofread.
Assuming jnos.org (my system) is going to be a backup for wetnet.net.
The domain entry for wetnet.net would have two MX records. A higher
priority entry for it's direct route and a lower priority (higher MX value)
for jnos.org:
-- wetnet DNS lines --
wetnet.net. IN MX 0 wetnet.net.
wetnet.net. IN MX 10 jnos.org.
----
On Jnos.org, I have to configure it to allow relaying for wetnet.net. That's simply
a matter of adding "wetnet.net" to /etc/mail/relay-domains and restarting sendmail.
So, as I understand it, jnos.org will now receive and cache messages going to wetnet.net
entries if wetnet.net is down.
Is it really that simple?
73,
Bill - WA7NWP
PS. See the end of this Wiki Page: http://www.jnos.org/cgi-bin/moin.cgi/WetnetSmtp
Friday, July 05, 2002
To: "TAPR ORG Discussion List"
Subject: [tapr-org] Amateur TCP mailing list
Many packets ago, we had a TCP-GROUP mailing list hosted at
UCSD. Before it died a far too colorful death, it was the core of
discussions for TCP and Amateur Radio networking.
Today we have several lists that cover portions of TCP/IP and
Amateur Radio, such as NETSIG, BBSSIG and Linux-Hams, but
no list focused there.
I propose that this would be a good thing. We have backbone providers
and ISP's disappearing, homeland security issues and on the fun side,
incredibly cheap technology available. It's time for a revitalization
of the Amateur TCP system. Would TAPR be interested in hosting
a "TCPSIG" list?
73,
Bill - WA7NWP
Subject: [tapr-org] Amateur TCP mailing list
Many packets ago, we had a TCP-GROUP mailing list hosted at
UCSD. Before it died a far too colorful death, it was the core of
discussions for TCP and Amateur Radio networking.
Today we have several lists that cover portions of TCP/IP and
Amateur Radio, such as NETSIG, BBSSIG and Linux-Hams, but
no list focused there.
I propose that this would be a good thing. We have backbone providers
and ISP's disappearing, homeland security issues and on the fun side,
incredibly cheap technology available. It's time for a revitalization
of the Amateur TCP system. Would TAPR be interested in hosting
a "TCPSIG" list?
73,
Bill - WA7NWP
Thursday, July 04, 2002
To APRSSIG
----
--
> Also, are there any plans to evolve to 9600 baud one of these days, since
> traffic congestion seems to be getting steadily worse?
Wont help much. A 9600 baud stand-alone single packet is hardly any
shorter than the 1200 baud very compressed packet format used by the
Kenwoods. Thus the savings is not even a factor of 2, yet the RANGE
performance is 4 times worse...
THough This area is certainly open for RESEARCH!
de WB4APR@amsat.org, Bob
--
That has nothing to do with 1200 vs 9600 - it's the hardware being used. Good
9600 baud radios can run with Transmit delays in the range of 50 milliseconds
or less. Typical 1200 baud radios should work well in the 300 to 350 millisecond
range. Thus the 8 to 1 speed improvement of 9600 to 1200 is maintained.
On the other hand, setting up a 9600 baud system is significantly more effort
then 1200 so it can be argued that low throughput applications like basic APRS
would not be worth the effort.
73,
Bill - WA7NWP
to APRSSIG
---
>At 03:34 PM 7/4/02 -0400, Ralph Milnes wrote:
>Wait a minute .. I'm confused about paths.
>Assuming a packet is addressed to APRS VIA RELAY, WIDE.
>I have been told by a very knowledge person on this SIG that if a WIDE digi hears that packet -- EVEN IF >A "RELAY" DIDN'T RELAY IT -- it will still digi the packet because it sees its alias (WIDE) in the address. In other >words, if a WIDE hears the packet direct from the sending station, it will digi it -- it doesn't need to hear the
> packet from the RELAY.
No. That's called Pre-emptive digipeating. Normally the digi's must be in order. First the
RELAY, then the WIDE. In Pre-emptive digipeating, one path entry preempts the earlier
ones.
Only Digi_ned, and the very latest UIDIGI, can be configured to do this.
Bill, WA7NWP
to APRSSIG
---
>Also, are there any plans to evolve to 9600 baud one of these days, since traffic congestion seems to be getting steadily worse?
>
>Thanks,
>Terry
Any individual group or area can create their own APRS cell using any frequency
and any baudrate. The key is to have at least one Igate bringing their packets
in to the core servers.
The Seattle area currently has two supplemental cells. One of a pair of
digi's on 440 with a nice quiet channel so it's acceptable to run
mobile beacons with a much faster transmission rate. The other "cell" is a 9600
baud digital repeater used primarily for TCP/IP traffic. The local APRS traffic
is barely noticeable on a faster system without the overhead of digipeaters.
73,
Bill - WA7NWP
Tuesday, July 02, 2002
Date: Tue, 02 Jul 2002 13:38:59 -0700
From: Bill Vodall - WA7NWP
Subject: Re: bandwidth tests
>At any rate, the "lolipop" router topology (one ad-hoc interface
>connected to multiple peers) with hidden nodes appears to really hammer
>the bandwith.
>
>-Chuck
This is one of the earliest lessons learned from Amateur Radio packet
networking. The cheap and easy "digipeater" style node was
trivial to build. Unfortunately, using that technology, hidden transmitters
were a major issue and performance took a serious hit.
Later backbone nodes used a scheme similar to what's being presented
on SWN using dedicated links to other backbone nodes with separate
user access channels.
Multiple local radios (802.11b cards) with out some separation or directional
antennas could likewise be causing cross channel interference and degrading
throughput.
Bill
From: Bill Vodall - WA7NWP
Subject: Re: bandwidth tests
>At any rate, the "lolipop" router topology (one ad-hoc interface
>connected to multiple peers) with hidden nodes appears to really hammer
>the bandwith.
>
>-Chuck
This is one of the earliest lessons learned from Amateur Radio packet
networking. The cheap and easy "digipeater" style node was
trivial to build. Unfortunately, using that technology, hidden transmitters
were a major issue and performance took a serious hit.
Later backbone nodes used a scheme similar to what's being presented
on SWN using dedicated links to other backbone nodes with separate
user access channels.
Multiple local radios (802.11b cards) with out some separation or directional
antennas could likewise be causing cross channel interference and degrading
throughput.
Bill
to qrz.com discussions
---
Quote (kg6ath @ July 01 2002,18:14)
The INTERNET will stay up (mostly) but nobody will be
able to access it. STRIKE-2
Amateur digital technology can provide the last mile link from still functioning Internet services to inside the affected area of an event... We can still have Internet when the phones are gone.
to APRSSIG mailing list
---
At 07:49 PM 7/1/02 -0400, Ralph Fowler wrote:
>The ID/NOID discussion on KPC 3 digis is basically a religious issue for Bob,
It's not a Ford vs Chevy issue. There is a major difference in the information content
available in the packets received.
ID on is like having telephone caller-ID that gives you your own phone number every
time you get a phone call.
NOID tells you where the packet is coming from.
>and so is the issue of not having a RELAY alias in California. Local decisions sometimes override what everyone else does for various reasons that may or may not be explainable or understandable.
Some areas that don't support RELAY have very valid and explainable reasons for what they do. But
breaking a national convention is something that shouldn't be done.
(And least I be too much of a BB supporter, the Kenwood D700 is guilty of the same... )
Bill - WA7NWP
---
At 07:49 PM 7/1/02 -0400, Ralph Fowler wrote:
>The ID/NOID discussion on KPC 3 digis is basically a religious issue for Bob,
It's not a Ford vs Chevy issue. There is a major difference in the information content
available in the packets received.
ID on is like having telephone caller-ID that gives you your own phone number every
time you get a phone call.
NOID tells you where the packet is coming from.
>and so is the issue of not having a RELAY alias in California. Local decisions sometimes override what everyone else does for various reasons that may or may not be explainable or understandable.
Some areas that don't support RELAY have very valid and explainable reasons for what they do. But
breaking a national convention is something that shouldn't be done.
(And least I be too much of a BB supporter, the Kenwood D700 is guilty of the same...
Bill - WA7NWP
Monday, July 01, 2002
to NWAPRS SIG mailing list
---
After being down for a couple months, my NWPRS play toy is running again.
I'm now documenting the project on the wiki..
http://www.jnos.org/cgi-bin/moin.cgi/NWPRS
The usage counter is running:
http://www.jnos.org/nwprs_usage.html
(There sure is a lot of WIDE5 paths and Winaprs 2.4.6 stations showing up... :-( )
As a bonus, I now have satellite locations being posted in real time
on the Private Channel, (10155) of JNOS.ORG. Any data uploaded to
the private channel is sent ONLY to other folks on the private channel. It
is not archived nor uploaded to any of the upstream APRS servers.
Check it out...
73,
Bill - WA7NWP
PS. For my other packet ramblings, check out http://wa7nwp.blogspot.com
---
After being down for a couple months, my NWPRS play toy is running again.
I'm now documenting the project on the wiki..
http://www.jnos.org/cgi-bin/moin.cgi/NWPRS
The usage counter is running:
http://www.jnos.org/nwprs_usage.html
(There sure is a lot of WIDE5 paths and Winaprs 2.4.6 stations showing up... :-( )
As a bonus, I now have satellite locations being posted in real time
on the Private Channel, (10155) of JNOS.ORG. Any data uploaded to
the private channel is sent ONLY to other folks on the private channel. It
is not archived nor uploaded to any of the upstream APRS servers.
Check it out...
73,
Bill - WA7NWP
PS. For my other packet ramblings, check out http://wa7nwp.blogspot.com
