开云体育

Hi Roger, tnx for your reply, will investigate and let you know how it goes.
73 de Neil G0SVN

In article <Version.32.19990702224859.00ea9440@...>, Neil
Savin <neil@...> writes

From: Neil Savin <neil@...>

Hi All, have just fired up a copy of ui-view, previous to this I have used
WinAPRS. I am RXing signals, I see them OK via "mh" in terminal but I see
no icons on the map.

Seems to work OK when I switch back to WinAPRS. I am using a TNC in
terminal mode and I have edit initnc.cmd as instructed.

You've got something wrong with your TNC settings. Open the "Comms
Setup" dialogue, press F1 and read the "Host mode NONE" section.
(Assuming you are using host mode NONE.) If you've got an AEA TNC, take
particular note of the comments about the PK232.

If that doesn't help you find your problem, use the Save option on the
Terminal window and send me the file.

--
Roger Barker, G4IDE roger@...
Boston, UK

From: "Jon Eyes" <jon@...>

Hi Dave,

Also on .800, but on the other side of the hills to you.

Your call was spotted by a station in Manchester last night....

Thanks John,

Yes, managed quite a chat with a station in the Manchester area. Hope to
see you on 800 soon?

Cheers de Dave (G0DJA)

Hi All, have just fired up a copy of ui-view, previous to this I have used
WinAPRS. I am RXing signals, I see them OK via "mh" in terminal but I see
no icons on the map.

Seems to work OK when I switch back to WinAPRS. I am using a TNC in
terminal mode and I have edit initnc.cmd as instructed.

Any ideas?

73 de Neil G0SVN

Well, quite an active couple of weeks, one way or another, from here. The
withdrawal of the 12.5kHz spaced frequency proposal, the allocation of
144.800MHz and, just as a few people start trying 800 out, a reasonable lift
to show what can be achieved with a nice clear frequency.

However, as I type this, I seem to be the only 'local' who is leaving their
rig monitoring 800 for most of the time, so I guess that it will take a
while for the frequency to become well used.

I've had a couple more requests for copies of the UI-View installation
program, and a couple of non-UK stations asking if they can have a copy. So
far, I've been able to persuade the non-UK stations that I'm not able to
send them a copy until Roger is happy that most of the major problems are
sorted, but I think there is a level of interest beyond our own 'patch' in
trying the program out.

I've not seen any APRS activity on 800 from around here yet, but then many
of the stations, in this area, who were experimenting with APRS seem to be
using UI-View now.

Debate on the BBSs seems to be raging anew, however, many of the arguments
seem to relate to problems with other systems or programs, like BPQ and/or
AGW, rather than UI-View as such. The trouble is that, possibly for the
vast majority of readers, because the debate is addressed to UIVIEW the
assumption is sometimes made that it is the fault of that particular
program. Most problems seem, to me, to boil down to either a setting that a
particular person has chosen in an associated program, or is inherent in the
packet system in particular areas of the country. No doubt when UI-View is
no longer flavour of the month, then the debate will move onto other topics.....

I'm still leaving the HF port monitoring on 20M and getting quite a
collection of stations from around the world plotted. I've not had any
response to my frequent pleas for others to try HF, or even other VHF bands
than the 'normal' ones. But I guess it is early days yet. I would like to
see what could be done with slower speed, narrower band, packet on, say, 4M
or 6M. One of the 'problems' with experimenting with propagation on HF with
packet is that unattended operation is not allowed in the UK. However, I do
leave the HF side running for as long as I can, but occasionally like to use
the HF rig for other modes as well. HI!

I wonder what is happening in other areas of the country?

de Dave (G0DJA)

In article <E10zlSz-00074B-00@...>, Dave Ackrill
<dave.g0dja@...> writes
[snip]

I've had a couple more requests for copies of the UI-View installation
program, and a couple of non-UK stations asking if they can have a copy. So
far, I've been able to persuade the non-UK stations that I'm not able to
send them a copy until Roger is happy that most of the major problems are
sorted, but I think there is a level of interest beyond our own 'patch' in
trying the program out.

Just to clarify this point - The reason for the restriction on
circulation is that, at the moment, I'm not prepared to even attempt to
support UI-View users outside the UK. I simply haven't got the time.

Letting it circulate overseas but refusing to support it is not an
option, because that would result in global slagging off of both me and
the program. Slagging off within the UK is quite sufficient... ;-)

--
Roger Barker, G4IDE roger@...
Boston, UK

Hi Dave,

Also on .800, but on the other side of the hills to you.

Your call was spotted by a station in Manchester last night....

~~~~~~~~~~
Jon Eyes G7OMN
Southport UK.

In article <000001bec3e5$bb8f2440$2bb4883e@pentium166>, Chris McCarthy
<chris@...> writes

From: "Chris McCarthy" <chris@...>

Hi Roger, I've seen a car change to a house a few times, wonder if you have
seen this happen?
I have only seen it happen where stations are using compressed data, I
think from the TH7DE, so whether its a TH7DE fault I don't know.

19:21:13R G7LEE-7>URPSW2,RELAY,WIDE <UI R Len=18>:
`w&]l!4[/>RICHARD

^ that's a jogger. In UI-View at the moment it will show as the
default of a house, unless you've added your own jogger
symbol to SYMBOLS.TXT and SYMBOLS.BMP.

----------edited

19:23:37R G7LEE-7>URPSW3,RELAY,WIDE <UI R Len=18>:
'w&&#92;l+4>/>RICHARD

^ that's a car.

He changed his symbol.

--
Roger Barker, G4IDE roger@...
Boston, UK

Hi Roger, I've seen a car change to a house a few times, wonder if you have
seen this happen?
I have only seen it happen where stations are using compressed data, I
think from the TH7DE, so whether its a TH7DE fault I don't know.

19:21:13R G7LEE-7>URPSW2,RELAY,WIDE <UI R Len=18>:
`w&]l!4[/>RICHARD
19:21:16R G7LEE-7>URPSW2,RELAY*,WIDE* <UI R Len=18>:
`w&]l!4[/>RICHARD

----------edited

19:23:37R G7LEE-7>URPSW3,RELAY,WIDE <UI R Len=18>:
'w&&#92;l+4>/>RICHARD
19:23:37R G7LEE-7>URPSW3,RELAY*,WIDE <UI R Len=18>:
'w&&#92;l+4>/>RICHARD
19:23:38R G7LEE-7>URPSW3,RELAY*,WIDE* <UI R Len=18>:
'w&&#92;l+4>/>RICHARD
19:23:41R G7LEE-7>URPSW3,RELAY*,WIDE* <UI R Len=18>:
'w&&#92;l+4>/>RICHARD

Cheers Chris G3XVL
chris@...

Test

Hi all,

I'd like to attempt to start an SSID standard for the Kenwood TH D7. This
idea came from the States, but it's a good idea. If you tried sending
messages with one of these you'll know why! It takes a bit of time ;-)

Anyway, could all D7 owners please use the SSID of 7 (remember to set the
icon using menu 2-5) that way people will understand not only that messaging
is slow, but they can infact send messages to you! THD7s beat dumb trackers
any day!

73...Ciemon G0TRT

Hi all,

I've sent this to the UKAPRS and UI-View lists as well as uk.radio.amateur

Why?

So that all those using 144.800 have an understanding of how digipeating
works with APRS/UI-View at the moment. There is obviously more than one way
to skin a cat, but this is what the US has come up with in all the years
that APRS has been used there. Seems a good a system as any to start with!

It's an extract from digis.txt, one of the readme files in APRSDos written
by WB4APR. I realise its a bit long winded, but it's INVALUABLE.

73...Ciemon G0TRT


BACKGROUND: The range of any AX.25 packet may be extended by
specifying one or more digipeater callsigns in the UNPROTO PATH. The
packet will be relayed by each such digipeater in turn. After each
such digipeat, that callsign is marked as used up so that at any
instant, only the "next" digipeater in the list has the potential to
digipeat the packet. Normally this requires users to know the complete
intended path for their packets.
APRS, however, satisfies its real-time, emergency tactical needs
without prior knowledge by using generic callsigns. ALL APRS stations
are given the generic digipeater callsign of RELAY and all digipeaters
are aliased as WIDE. This way any station can use any digpeater by
using an UNPROTO path of WIDE or he can use any other station as a
digipeater by simply addressing the packet VIA RELAY. With this
generic digipeating, a mobile, or new station does not have to know
anything about the network in advance in order to be seen by adjacent
nodes. After 10 minutes and his map begins to show the location of
all stations and digipeaters on frequency, he can then customize his
outgoing Unproto path to specific digipeater callsigns to cover his
intended area without as much QRM.

ROUTES: It is important that as APRS networks mature with fixed, known
digipeaters, that users at FIXED stations should avoid using the
generic RELAY or WIDE addressing. Although it still makes sense for
mobiles to use the path of RELAY,WIDE, the path of RELAY should rarely
be used after the first hop by ANYONE, and never after a WIDE.
Remember, every packet addressed via RELAY will key up EVERY APRS
station that hears it. In any but the sparsest areas, the result is
total congestion and collisions which block anyone from copying the
packet.

APRS DIGIPEATERS: Wide area APRS digipeaters should be widely
separated to provide long distance coverage with the minimum of hops.
If there is a need for interim digipeaters to fill in weak signal
areas or valleys, then they should be installed as needed but ONLY
with the RELAY alias.

MODERN APRS DIGIPEATING: At Dayton 97, PacComm introduced their new
TNC ROMs which will substitute their callsigns in place of their
generic Aliases whenever a packet is digipeated. The big advantage
besides tracebility is that they will also IGNORE the packet from then
on completely eliminating looping duplicate packets. This was a great
advance for APRS! This was followed in 1998 with Kantronics
implementing the APRS WIDEn-n algorithm which further improves
multi-hop efficiency.

WIDE DIGIPEATING: Although in start-up areas any TNC can be used as a
WIDE digi simply by setting its MYALIAS to WIDE and its BText to
include its APRS position, this is NOT recommended today in areas
within a mature APRS environment. Today, only TNC's with the new
PacComm 4.0 and Kantronics 8.2 Roms or later should be used. They
should be set up with the four generic calls of RELAY, WIDE, TRACE and
your state abbreviation. The functions of each of these generic
aliases are as follows:

RELAY - The universal default for all APRS stations
WIDE - Provides WIDE area digipeating
TRACE - Identical to WIDE, but helps identify only the new
digipeaters capable of these advanced routing capabilities
SS - Useful for state wide only digipeating

HOME STATIONS should never use any alias other than RELAY without the
full consent of the surrounding users and network planners.

TRACE DIGIPEATERS: Although all 4 aliases are treated equally, using
the TRACE call has some important advantages. Most important, it
allows for usage of the new anti-duping features in advance of waiting
until all WIDEs are converted to the new ROMS. As long as there are
any old WIDE only digipeaters, anything beyond WIDE,WIDE cannot be
used or it will result in bad duplications. But by using the
equivalent TRACE,TRACE,TRACE, the packet takes advantage of the new
digis without triggering the old ones.

MOBILES: Mobiles typically use the path of RELAY,WIDE because they
may be out of range of a WIDE digipeater but be near someone's home
station acting as a RELAY. Even if WIDE digipeaters are 30 to 50
miles apart, as long as every home station and local RELAY digipeater
can hit at least one WIDE, then the mobile path of RELAY,WIDE can
cover as far as 100 miles! Wider ranging mobiles can use the
RELAY,WIDE,WIDE path without causing too much QRM because of their low
antennas. BUT CONVERSLY, RELAY,WIDE,WIDE should NEVER be used by a
home station since he will undoubtedly hit many home RELAYS all at the
same time and therefore generate numerous dupes with every packet.

CAUTION: Fixed stations that can hit 2 or more WIDES should NEVER use
three generic RELAY/WIDE callsigns in a row, and RELAY should NEVER be
anywhere except the FIRST in the list. Multiple TRACE hops are fine
but you should not plan on QRMING beyond your immediate area except as
needed. Although generic paths for mobiles are the normal, special
consideration must be given whenever there will be a great convergence
of generic mobiles using RELAY,WIDE paths, since each of them will
repeat each other! In this case, they should change the path to NOT
begin with RELAY.

OPERATIONS WITH RELAY AND WIDE:

Although the GENERIC WIDE/RELAY digipeating works well to get an
APRS net going, once you have more than two WIDES, the generic calls
should be avoided by all fixed stations to minimize unnecessary
duplicates and collisions. Or use TRACE. Using SPECIFIC callsigns
significantly reduces
QRM. A path of WIDE,WIDE,DIGI3,DIGI4 will get you out 2 hops in all
directions and 4 more hops in the direction of DIGI3 and DIGI4.
BACKGROUND: The range of any AX.25 packet may be extended by
specifying one or more digipeater callsigns in the UNPROTO PATH. The
packet will be relayed by each such digipeater in turn. After each
such digipeat, that callsign is marked as used up so that at any
instant, only the "next" digipeater in the list has the potential to
digipeat the packet. Normally this requires users to know the complete
intended path for their packets.
APRS, however, satisfies its real-time, emergency tactical needs
without prior knowledge by using generic callsigns. ALL APRS stations
are given the generic digipeater callsign of RELAY and all digipeaters
are aliased as WIDE. This way any station can use any digpeater by
using an UNPROTO path of WIDE or he can use any other station as a
digipeater by simply addressing the packet VIA RELAY. With this
generic digipeating, a mobile, or new station does not have to know
anything about the network in advance in order to be seen by adjacent
nodes. After 10 minutes and his map begins to show the location of
all stations and digipeaters on frequency, he can then customize his
outgoing Unproto path to specific digipeater callsigns to cover his
intended area without as much QRM.

ROUTES: It is important that as APRS networks mature with fixed, known
digipeaters, that users at FIXED stations should avoid using the
generic RELAY or WIDE addressing. Although it still makes sense for
mobiles to use the path of RELAY,WIDE, the path of RELAY should rarely
be used after the first hop by ANYONE, and never after a WIDE.
Remember, every packet addressed via RELAY will key up EVERY APRS
station that hears it. In any but the sparsest areas, the result is
total congestion and collisions which block anyone from copying the
packet.

APRS DIGIPEATERS: Wide area APRS digipeaters should be widely
separated to provide long distance coverage with the minimum of hops.
If there is a need for interim digipeaters to fill in weak signal
areas or valleys, then they should be installed as needed but ONLY
with the RELAY alias.

MODERN APRS DIGIPEATING: At Dayton 97, PacComm introduced their new
TNC ROMs which will substitute their callsigns in place of their
generic Aliases whenever a packet is digipeated. The big advantage
besides tracebility is that they will also IGNORE the packet from then
on completely eliminating looping duplicate packets. This was a great
advance for APRS! This was followed in 1998 with Kantronics
implementing the APRS WIDEn-n algorithm which further improves
multi-hop efficiency.

WIDE DIGIPEATING: Although in start-up areas any TNC can be used as a
WIDE digi simply by setting its MYALIAS to WIDE and its BText to
include its APRS position, this is NOT recommended today in areas
within a mature APRS environment. Today, only TNC's with the new
PacComm 4.0 and Kantronics 8.2 Roms or later should be used. They
should be set up with the four generic calls of RELAY, WIDE, TRACE and
your state abbreviation. The functions of each of these generic
aliases are as follows:

RELAY - The universal default for all APRS stations
WIDE - Provides WIDE area digipeating
TRACE - Identical to WIDE, but helps identify only the new
digipeaters capable of these advanced routing capabilities
SS - Useful for state wide only digipeating

HOME STATIONS should never use any alias other than RELAY without the
full consent of the surrounding users and network planners.

TRACE DIGIPEATERS: Although all 4 aliases are treated equally, using
the TRACE call has some important advantages. Most important, it
allows for usage of the new anti-duping features in advance of waiting
until all WIDEs are converted to the new ROMS. As long as there are
any old WIDE only digipeaters, anything beyond WIDE,WIDE cannot be
used or it will result in bad duplications. But by using the
equivalent TRACE,TRACE,TRACE, the packet takes advantage of the new
digis without triggering the old ones.

MOBILES: Mobiles typically use the path of RELAY,WIDE because they
may be out of range of a WIDE digipeater but be near someone's home
station acting as a RELAY. Even if WIDE digipeaters are 30 to 50
miles apart, as long as every home station and local RELAY digipeater
can hit at least one WIDE, then the mobile path of RELAY,WIDE can
cover as far as 100 miles! Wider ranging mobiles can use the
RELAY,WIDE,WIDE path without causing too much QRM because of their low
antennas. BUT CONVERSLY, RELAY,WIDE,WIDE should NEVER be used by a
home station since he will undoubtedly hit many home RELAYS all at the
same time and therefore generate numerous dupes with every packet.

CAUTION: Fixed stations that can hit 2 or more WIDES should NEVER use
three generic RELAY/WIDE callsigns in a row, and RELAY should NEVER be
anywhere except the FIRST in the list. Multiple TRACE hops are fine
but you should not plan on QRMING beyond your immediate area except as
needed. Although generic paths for mobiles are the normal, special
consideration must be given whenever there will be a great convergence
of generic mobiles using RELAY,WIDE paths, since each of them will
repeat each other! In this case, they should change the path to NOT
begin with RELAY.

OPERATIONS WITH RELAY AND WIDE:

Although the GENERIC WIDE/RELAY digipeating works well to get an
APRS net going, once you have more than two WIDES, the generic calls
should be avoided by all fixed stations to minimize unnecessary
duplicates and collisions. Or use TRACE. Using SPECIFIC callsigns
significantly reduces
QRM. A path of WIDE,WIDE,DIGI3,DIGI4 will get you out 2 hops in all
directions and 4 more hops in the direction of DIGI3 and DIGI4.

I run Winpack V6.4 here and as I understand it can use the beacon on
that
but I could be wrong. Please correct me if I am wrong at that.
Not sure where GB7GP is.

Neither am I, but it reaches the mainland UK well when the conditions
are right. Winpack does not control the beacon as such, your TNC
firmware should do that. If you need assistance setting up a beacon,
I'd be pleased to help. Better to do it over email though rather than
through this newsgroup. My email address is: M1DOX@...

Please excuse me if the message is a bit garbled as I have just come
out of
hospital this morning after 26hr. drip on "Chemotherapy" which I have
every
three weeks and it takes the brain a few days to come down to earth
again.

No problem, the way my brain works I understand cryptic messages better
than well written ones :-) I hope that your feeling more yourself again
now, and that the chemotherapy is having a positive effect.

As I may have said before our e-mail is sent it the UK. IPPLIPEN I
believe
once a week, so this mode is faster.

Aha, I never realised that, but it does make sense.

Apologies to all who didn't want to read this, but I don't have Ron's
email address. I hope to continue this thread in email.

Nik.
M1DOX.

The location here is 6 ft. below High Tide level at Spring tides so its not
that good at UHF or VHF for putting signals out.
And on a regular basis most of us, even those on High Ground that is 340 ft.
at our Airport, do not use UHF/VHF on a regular basis.
I run Winpack V6.4 here and as I understand it can use the beacon on that
but I could be wrong. Please correct me if I am wrong at that.
Not sure where GB7GP is.

Please excuse me if the message is a bit garbled as I have just come out of
hospital this morning after 26hr. drip on "Chemotherapy" which I have every
three weeks and it takes the brain a few days to come down to earth again.

As I may have said before our e-mail is sent it the UK. IPPLIPEN I believe
once a week, so this mode is faster.

73 RON

Here in Portsmouth, when there is a lift on on UHF I can sometimes see
GB7GP direct (and connect to it), if not via GB7IW. If you could beacon
via GB7GP, it would be an excellent guide to propagation conditions.

I've been following the argument about digipeating/not digipeating
beacons, but having had a good look at the MH lists on GB7GP I don't
think that it will impact traffic at all.

Hi Karl

Stations heard on 144.800 morning 17 July 1999 from

000.36.60W 52.19.75N (IO92QI)

Callsign miles Last heard
G3NRW 25.6 JUL 17 13:38
G0TRT* 64.0 JUL 17 08:52
+G3ZCV* 71.3 JUL 17 08:46

<snip>

Useful reports - what I can't work out is why
my call hasn't appeared on one yet. I have heard
G4VQZ, G7BHM, G4IDE, G3NRW, G0TRT (sometimes mobile) and some
of the others on your list over the past week or so.
I have my UNPROTO path set to RELAY,WIDE but my beacons do
not seem to be getting very far...

I was beginning to think I had a hardware problem this
end but I can work into the GB7DID BBS (25miles to the
North West of me) reliably on 144.850MHz suggesting
everything is set up OK.

Todays (17th) monitoring has brought in:

G4VQZ - Last heard a few minutes ago (23:27)
G0TRT-7 - Last heard at 09:47

...and that is all - monitoring for most of the day.

Cheers

Denis G4KWT

Sorry I repeated this message to GBR on Packet it was meant to those
stations locally on GB7GSY.
As far as I know at the present I am the only station using UIVIEW in the
Channel Islands.
It will be nice to have a few more around as our link to UK at present is by
e-mail only.

Do remember that I have a spare house next door , if you should ever need a
break from VAT and the Common Market.

73 RON

The following is a copy of a packet message sent to DCCINF@GBR by G1DVU on
behalf of the DCC. Apart from the use of 144.800, please note the comment
about whether "unconnected nets" users have a requirement for a 70cm
frequency.

**
From :G1DVU @GB7SXE.#38.GBR.EU
To :DCCINF@GBR
Date/time :18-Jun 21:36
Title :DATA BANDPLAN CHANGES

Subsequent to the extensive consulation exercise, and after careful
consideration of all input received, the Data Communications Commitee
has agreed with the VHF Committee the following changes within the 4M,
2M and 70 CM bands:


4M
=====

70.3625, 70.3875, 70.4125 and 70.4375 MHz will be marked as 'Digital
Modes'.


2M
======

From input received regarding the use of both 144.500 and 144.700 MHz,
it became apparent that a different solution needed to be sought to find
an accomodation for the 'unconnected net' traffic (APRS, UIView, et al)
within the current spectrum allocated to digital communications. As a
result, DCC proposed that one of the 9600 bps channels (144.825 MHz) may
be redesignated as 3 x 12.5 kHz channels, and that 144.8125 MHz would
then be recommended for such use.

Again, from input received, it is apparent that the UK users of amateur
digital communications believe that the loss of this particular channel
would have far reaching implications upon the growth potential for high
speed network access facilities.

With this in mind, and considering input received from Holland (who also
sent comments regarding Germany and Belgium), the VHF Committee has
recommended that 144.800 MHz now be marked as 'unconnected nets'. DCC is
pleased to report that, given all available information, it is entirely
in agreement with VHF Committee's recommendations.

Users of 144.800 MHz for digital communications are reminded that their
FM deviation should be adjusted to a MAXIMUM of +/- 2.3 kHz in order to
prevent interference to users of 144.7875 MHz (within the 'all modes
section) and 144.825 MHz.

However, the pressure upon user access frequencies within the 2M band
remains high, and in order to provide further scope, it is now envisaged
that - subject to local agreement - 144.825 MHz may need to be shared
by both 1200 bps and 9600 bps stations. Additionally, it is forseeable
that Mailbox NoV's might now be issued to include 144.9125 MHz.



70CMS
=====

After further detailed consultation with various interested organizations
(including BATC), the RSGB's VHF Committee has agreed an additional
allocation for digital modes at 433.800 - 434.250 MHz. In order to reduce
the potential for interference to ATV users, only vertical polarisation
should be employed in this sub-band.

DCC welcomes this additional allocation, and has nominally agreed that
433.800 - 434.000 MHz will be allocated as "user" frequencies, while
434.000 - 434.250 MHz will be allocated as "linking" frequencies.

To enable detailed planning to take place, it would be helpful for DCC to
know whether the "unconnected nets" users have a perceived requirement
for an allocation within the 433.800 - 434.000 MHz segment.



No further changes are proposed to any of the above bands without further
detailed consultation.

Should you require more information, or wish to comment further, please
address your messages to either the DCC Chairman: G0RDI@GB7SXE.#38.GBR.EU
or by EMail to: bandplan@...


Martin Green G1DVU
DCC UK Mailbox Coordinator

---------------------------------------------------------------------------
Martin Green G1DVU/M0BMD @ GB7SXE - Internet, marting@...
Telephone 01424-755192 (Not after 10-00pm!)
Fax 01424-755916, Mobile 0850-072652
---------------------------------------------------------------------------
**

--
Roger Barker, G4IDE roger@...
Boston, UK

1:Fm R0MIR To QST <UI pid=F0 Len=47 >[08:28:04]
:BLN1 :Please enjoy APRS UNPROTO Via R0MIR
1:Fm R0MIR To QST <UI pid=F0 Len=67 >[08:30:55]
:BLN2 :The MIREX team & crew sends greetings to ALL World Wide

--
73 de Ken

Try this !



73'de Ronald.SM7WDL