开云体育

To try and summarise the situation:-

1. The sample maps supplied with UI-View are all GIFs and are all size
800x600.

2. There is no scaling or stretching of the maps when loaded. Therefore
at a resolution of 800x600 or lower, they should display with a scroll
bar. At 1024x768 or higher they should only partially fill the screen,
and there should be a grey area to the right of and below the map.

3. If you create your own maps, they can be BMPs or GIFs. BUT if you
create BMPs and put them in the UI-VIEW\MAPS directory, and then make
them into GIFs but don't delete the BMPs, UI-View uses the BMPs in
preference to the GIFs.

4. I have found a problem with V0.74b that causes it not to correctly
size the window when loading BMPs. It leaves it at whatever size it was
before the BMP was loaded.

I have now fixed '4', but obviously I don't want to upload the fix if
there are some other problems that I'm not seeing.

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

I agree with John.

Some maps are being chopped, some are reduced in size. Some work
OK, but not all.

Keith

Hi all,

This is a bit long, but stick with it!

As a longtime APRS user I can tell you that this attitude will spread very
quickly amongst BBS users. The latest case I can quote happened, and to a
certain extent still does, from stations in the Norwich area. I managed to
get three BBS to include their APRS posn and a number of end users to not
only change their btext but also have a go with the software.

But a lot of complaints, even to the DCC, about use of APRS led to the BBS'
removing their posns to keep users happy. At the time we were using 144.850,
my WIDE digi was able to link, on a good day, the south coast, Suffolk and
up to G4IDE in Lincs, but only APRS beacons that were set to use RELAY WIDE.

Even though we stopped using APRS on the freq, the btexts didn't change as
everyone sends beacons. But still the complaints kept coming. Then a number
of complainers started beaconing every 6 mins things like..... Get APRS off
144.850..... Does APRS need an NOV. So we decided to move APRS activity off
the BBS access freq and went to 144.825. In Suffolk and the surrounding area
there is no 9k6 activity so it made sense to us. We've had no complaints at
all, there are three trackers, approximatley7 or so users and my WIDE digi
so activity isn't too bad.

The revised band plan that Iain Phillips released a while back made mention
of a dedicated APRS freq. Hopefully this will be confirmed when the
re-revised band plan is released in May (?). I urge you all to use that freq
to get the most from APRS/UI-View.

On the subject of unproto here is the thinking that has been developed over
the last 5+ years in the states:

The whole idea is to be able to communicate with anyone that is on your map
and also ensure maximum coverage for mobile and qrp stations. If we all used
any old alias for our digis then it would be complicated to achieve a wide
area of coverage. So ALL stations should have their alias set to RELAY those
that live on top of maountains or have good coverage should set it to WIDE.

So, we all set our unproto to RELAY WIDE or even RELAY,WIDE,WIDE to ensure
maximum coverage. Why do we need such coverage? Two examples:

1. I'm going to travel to Yorks from my qth in Suffolk. If we all use RELAY
and WIDE on our digi's then I can set my car trackers unproto to RELAY WIDE
and ensure maximum coverage without having to reprogram it enroute. Remember
I said that I can hear Lincs from my WIDE. SO if there's a WIDE in Lincs I
could be sat in Yorks with my 25 watt mobile and people on the south coast
could not only see me moving, but send me messages as well!

2. I'm on foot, in Ipswich with my THD7 that has the ability to send
messages. My unproto is RELAY,WIDE,WIDE. By using a RELAY in Ipswich, My
WIDE in Wattisham and a WIDE in Lincs I could be having a packet qso with
someone north of Roger!!

Hope you all understood all of that!

If any of you would like to join my APRSUK list it can be found at onelist
like this one.

73...Ciemon Dunville g0trt@...
APRS UK
!5207.40N/00058.35E-PHG7268/ QRA:JO02lc QTH Wattisham Suffolk

Hello Roger.

Another suggestion.

Can Off-Map locations be flagged up so that we know there are others about,
even if we can't see them on the currently loaded map?
Perhaps a callsign with an Arrow pointing to the direction the location is
off-map?

Thanks and 73, Mick O'Donnell

Phone/Fax:: +44 (0)1908 316052
Mobile : +44 (0)836 228084
E-Mail: mickodonnell@...
ICQ 27902590

From: Roger Barker <roger@...>

Also, anyone who can do a few sums can easily show that the total volume

of traffic being generated by UI-View use will pale into insignificance
compared to a user downloading a few bulletins from the BBS.

The real problem is that:-

(a) An attitude has developed in the UK that "packet = using the BBS
network", and the packet channels are to be used for nothing other than
accessing BBSs.

(b) Packet has almost ceased to be an amateur radio mode. Not only do
some users never think of packet in terms of self-training and
experimentation, but they complain if anyone else does!

As a Sysop here at Rugeley (GB7RUG), a BBS which looks after 40+ users, I
encourage the use of UI-VIEW on my mailbox 144.850Mhz port, via a seperate
machine running UI-View, interlinked to the main node and mailbox. I can
support no Sysop that doesn't! There is nothing to support the argument,
that UI-VIEW is taking over or increasing traffic on mailbox ports. The
mailbox and its users,
are unaffected by the passive UI frames, while they are connected to the
mailbox.


I take an active approach, by encouraging all my users to try experimentation
and new additions within Packet radio, whether it be hardware or software. If
we fail to try these new, modes, which encourage good software writers like
Roger, and hardware designers, where will packet Radio be in the next be in
the next 10years?


UI-View in the future will be a very valuable asset to Amateurs, and other
aspects of life in the future, its up to "all" to support it!



Steve (G1KQH) Sysop @ GB7RUG.#28.gbr.eu

In article <001401be89b2$fad50100$9bbd883e@ciemon>, Ciemon Dunville
<g0trt@...> writes

As a longtime APRS user I can tell you that this attitude will spread very
quickly amongst BBS users. The latest case I can quote happened, and to a
certain extent still does, from stations in the Norwich area. I managed to
get three BBS to include their APRS posn and a number of end users to not
only change their btext but also have a go with the software.

But a lot of complaints, even to the DCC, about use of APRS led to the BBS'
removing their posns to keep users happy. At the time we were using 144.850,
my WIDE digi was able to link, on a good day, the south coast, Suffolk and
up to G4IDE in Lincs, but only APRS beacons that were set to use RELAY WIDE.

[snip]

So, we all set our unproto to RELAY WIDE or even RELAY,WIDE,WIDE to ensure
maximum coverage. Why do we need such coverage? Two examples:

[snip]

Doesn't the above very much represent a self-fulfilling prophecy? ;-)

"You will get opposition from BBS users ... We need to set our digis to
RELAY,WIDE ..."

If people would read the following sections of the UI-View help -
"Introduction", "Station Setup" and "It Might Not Be For You..." - I
hope that I have made my opinion about the use of beacons and digis on
the BBS frequencies clear.

If/when you use the program other than on the BBS frequencies, the
caution I have advised doesn't apply. The reality, however, is that most
people are going to use it on the BBS frequencies, because that is where
their packet systems "live". No matter how good APRS is, few are going
to permanently move their systems onto a dedicated APRS frequency, even
when one is agreed.

What I see happening at the moment is that an image of UI-View is being
projected by comments to the UIVIEW packet topic, that wide area
digipeating is a prerequisite of using the program, which isn't true.

So, to repeat what I've said several times before - Do as much, or as
little in the way of digipeating as is locally acceptable. Don't create
local confrontation for the sake of making the program work better.

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

They already are Mick! They are shown in the Stations List, along with those
within the area of the current map.

--
73 - Roger G4ZEC <zec@...>

I never did understand the 'APRS needs an NoV' arguement. Can someone
explain what the reasoning was please?

As far as I can see, many stations send beacons and you have to identify in
some format. Since UI frames are used for unconnected packets, such as when
you unexpectedly loose a connection for some reason, or decide to call 'CQ'
(Now, that takes me back to the days before NODES and Digipeaters, when you
had to find someone else using packet to be able to connect at all. HI!)
then UI frames should be 'OK'. So, where the arguments against APRS based on?

That is, other than the usuall mistrust of anything new, or that is not
understood by the complainant. :o)

de Dave (G0DJA)

Any other users of the KAM+ on the list please?

If so, have you managed to solve the following problem with this TNC?

When using Host Mode (i.e., selecting 'NONE' mode in Comms Setup) incoming
UI frames from other users have the VHF identifier /V added. This means
that if I send a packet 'Hello' to, say, M0BCU-3 the following happens:-

KAM+ sends -
G0DJA-3>M0BCU-3: ~Hello~00

KAM+ receives an ACK, but decodes it as -
M0BCU-3>G0DJA-3/V: ~00

So UI-View doesn't recognise this as my callsign, not surprisingly, and
resends the message ~Hello~. M0BCU-3 responds with an ACK, but the KAM+
still doesn't recognise it as my callsign.

I've looked through the KAM+ instruction manual, but cannot see how to turn
off the /V from received packets in UI frames.

I would like, eventually, to use UI-View on HF as well as VHF, so would
prefer to be able to use NONE mode, rather than KISS (which works OK) which
seems only to address the VHF port on the KAM+.

Any ideas please?

Thanks de Dave (G0DJA)

Anyone using a KAM+ may find adding the following to the exit command
program (exitnc.cmd) useful.

I added two lines

M ON
B E 30

and amended the line MON OFF to

MC OFF

The first command (M ON) turns the monitor back on when reverting to normal
TNC mode,
B E 30 sets the Beacon Every command to 30 minutes. B E 30 is needed as
UI-View sets the TNC Beacon to Zero on setting up, to avoid double
beaconing, but on exiting the TNC needs to have the Beacon Every time reset.
(NB: If you want to send a beacon at something other than 30 minutes, alter
the figure to the number of minutes you want. An alternative is B A 'X' -
Beacon After, where the KAM will wait until the channel has not been used
for 'X' minutes before sending a beacon. Round here, that would be like
setting B E 0. HI.....)

MC OFF is needed otherwise the KAM+ will start to show packets from other
stations when you are connected to a station.

Hope these ideas help someone else.

Cheers de Dave (G0DJA)

They already are Mick! They are shown in the Stations List, along with

those

within the area of the current map.

--
73 - Roger G4ZEC <zec@...>

Maybe so, but nothing is flagged on the MAP, which is where, I would
suggest, most users would be looking at, if not doing anything else. It
would be nice to have a visual indication of direction of, off-map station
and callsign? Maybe I am missing something here, but I can't find it! :-)

Thanks and 73, Mick O'Donnell, g8ccv@gb7ben

Phone/Fax:: +44 (0)1908 316052
Mobile : +44 (0)836 228084
E-Mail: mickodonnell@...
ICQ 27902590

I've just uploaded the V0.75b update to my web site. Please note that
this is only an update, not a complete installation system. The update
can be applied to V0.6b or later and includes all the changes made since
that version, you don't need to apply the previous updates before
applying this one. The url is:-



Please don't publicise the link outside this mailing list. Also, because
the main feature of this update is an attempted bug fix, it's probably a
good idea not to pass it on to too many people until a day or two has
elapsed, to allow subscribers to the list to let me know if the fix has
worked.

I've released this update very soon after V0.74b because of the problems
that were reported with loading some maps. I have found a problem with
loading BMP format maps, but I have not found a problem with loading
correctly calibrated GIFs - for instance the ones that I supplied with
the program.

The problem I found was that the map window was not resized when loading
a BMP, the most obvious way to demonstrate it was to close UI-View with
a BMP loaded. When the program was restarted, the only part of the map
visible would be a small square in the top left corner of the map
window. If a BMP was loaded after a GIF map that filled the window, then
the problem would be less obvious, but the calibration would be wrong
unless the BMP was exactly the same size as the GIF.

If anyone still gets a problem with this version, using the maps I
supplied, then there is something I am missing, and I would need the
following information:-

Details of exactly what goes wrong
Version of Windows
Make and type of video card
Resolution being used
Whether "large fonts" are being used

If you get a problem with your own BMPs, please convert one of the maps
that I supplied to a BMP, and see if it also gives a problem.

Here is the relevant section of HISTORY.TXT:-

V0.75b 1999-Apr-19 1. A bug fixed in displaying BMP maps that was
introduced in V0.74b.
2. Had another go at the KAM frame header problem.
3. Slightly altered the auto close down logic when
WINPDDE mode is being use, and WinPack is closed
while UI-View is still running.
4. Support added for GPS $GPRMC sentence.
5. Support added for location data transmitted by
microphone encoder devices. (A microphone encoder
sits between the mic and the rig, and allows
position data to be sent on release of the PTT.)
The Kenwood TH-D7E also transmits this data
format.

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

In article <001001be8ac8$39fc9760$4519883e@g8ccv>, Mick O'Donnell
<mickodonnell@...> writes

From: "Mick O'Donnell" <mickodonnell@...>

They already are Mick! They are shown in the Stations List, along with

those

within the area of the current map.

--
73 - Roger G4ZEC <zec@...>

Maybe so, but nothing is flagged on the MAP, which is where, I would
suggest, most users would be looking at, if not doing anything else. It
would be nice to have a visual indication of direction of, off-map station
and callsign? Maybe I am missing something here, but I can't find it! :-)

I think you'll find that, the more stations you hear, the more you'll
use the Station List. I open it by default when UI-View starts, using
the /S command line option.

Also, if you load a series of maps - local, semi-local, UK, and Europe,
you can then flick through them with the <- and -> buttons and so
easily see what stations are off your local map.

I've had various thoughts about clicking a station in the list and
automatically loading a map on which that station will appear, moving
the map so the station is visible, highlighting it in some way, etc, but
that's a bit far in the future at the moment.

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

I prefer to label stations on the map with a smaller font than the default,
MS Sans Serif 8.25 Bold, using instead the condensed WinPack 9 this may be
done by editing UIVIEW.INI e.g:

[SETUP]
LABEL_FONTNAME=WinPack
LABEL_FONTSIZE=9
LABEL_FONTBOLD=FALSE
LABEL_FONTITALIC=FALSE

I would also like to be able to modify the font attributes in the Station
List, please Roger incidentally, I'm in agreement with Dave G0DJA over the
usefulness of this list, but would prefer to reduce its physical size.

Is it possible to save the vertical height of the main window
(non-maximised) when closing? When I re-open UI-VIEW, the top left and right
corners are always in the correct position, and the map is positioned
correctly as per the previous session, but the height of the window has
shrunk by about 20%. If it's relevant, my screen's at 1280x1024 and UI-VIEW
occupies the lower right quadrant of the display, at these co-ordinates:

MAP_LEFT=10080
MAP_TOP=6390
MAP_WIDTH=9120
MAP_HEIGHT=8550
MAP_MAXIMISED=FALSE

I always have to drag the lower edge to the bottom of the screen after
restarting UI-VIEW is this a fault or conditional on the map size etc.?

Finally, V0.75b is working fine with my .BMP files I left a few on my
system that I didn't convert to .GIF format.

Thanks for yet another splendid piece of innovation!

--
73 Roger G4ZEC <zec@...>

Sorry Mick, but I don't agree!

I usually check in the Stations list to see who has been heard before I load
a map. Even when I have a map loaded, I keep an eye on the Stations list
for new, incoming stations heard.

Call me 'strange' but even with a fairly close scale map, many stations are
plotted one on top of the other, so keeping the Stations list open tells me
of a new one plotted and then I load a suitably sized map to find them.

de Dave (G0DJA)

In my local area (Portsmouth), there are a few users living in close
proximity to each other. This results in the callsigns overwriting each
other, even on a map of large scale (they live within a couple of
hundred yards of each other).

Would it be possible when plotting the icon on the screen, to check to
see if the label would overwrite another station, and if so to place the
label on the other side of the icon?

Nik Price.
M1DOX.
Nik@...


Regards,
Nik.
www.aquacars.co.uk

In article <003a01be8b12$239e4640$156afea9@eve>, Roger Colwell
<zec@...> writes

I prefer to label stations on the map with a smaller font than the default,
MS Sans Serif 8.25 Bold, using instead the condensed WinPack 9 this may be
done by editing UIVIEW.INI e.g:

[SETUP]
LABEL_FONTNAME=WinPack
LABEL_FONTSIZE=9
LABEL_FONTBOLD=FALSE
LABEL_FONTITALIC=FALSE

The label font is also accessible from the station right-click menu,
"Font" option.

I would also like to be able to modify the font attributes in the Station
List, please Roger incidentally, I'm in agreement with Dave G0DJA over the
usefulness of this list, but would prefer to reduce its physical size.

That's a non-trivial one, for several reasons. Also, if I make the font
smaller and the list smaller, then I'd really have to make the buttons
smaller, or it would still take up as much room across the screen. What
if I make it so you can shrink the window? Losing information from the
right and bottom the more you shrink it?

Is it possible to save the vertical height of the main window
(non-maximised) when closing?

It's supposed to do that, and the next update will actually do it! ;-)

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

In article <41D9AF705DB0D1119E570020AF871A64D4E4@MAILSTORE>, Nik Price
<Nik@...> writes

From: Nik Price <Nik@...>

In my local area (Portsmouth), there are a few users living in close
proximity to each other. This results in the callsigns overwriting each
other, even on a map of large scale (they live within a couple of
hundred yards of each other).

Would it be possible when plotting the icon on the screen, to check to
see if the label would overwrite another station, and if so to place the
label on the other side of the icon?

In theory yes, but it would be difficult to implement. Also, when the
great day comes and you've got 100 stations on your map, there would be
an awful lot of time consuming checking of overlapping rectangles going
on every time the map refreshed.

If you regularly see these stations on your map, why not create a
special symbol for each of them, and check "Omit labels on special
symbols" in "Miscellaneous Setup"? Even if the special symbol is nothing
more than a rectangle containing the callsign, it will still take up
less room than a default symbol plus a label.

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

From: Roger Barker <roger@...>

In article <003a01be8b12$239e4640$156afea9@eve>, Roger Colwell
<zec@...> writes

<snip>

The label font is also accessible from the station right-click menu,
"Font" option.

I knew I'd seen it somewhere....! (Mutter, mutter...must RTFM...) ;-)

I would also like to be able to modify the font attributes in the Station
List, please Roger incidentally, I'm in agreement with Dave G0DJA over

the

usefulness of this list, but would prefer to reduce its physical size.

That's a non-trivial one, for several reasons. Also, if I make the font
smaller and the list smaller, then I'd really have to make the buttons
smaller, or it would still take up as much room across the screen. What
if I make it so you can shrink the window? Losing information from the
right and bottom the more you shrink it?

As it is now, the Station List window contents/menu/buttons use MS Sans
Serif in one point size, therefore how difficult would it be to dynamically
change the button size along with the one font?

As for shrinking the window on the bottom & right, not as the layout stands
as there is no menu...why is there no menu in this window when all the
others have them? And/or, could the bottom bar be dynamically stacked into
two rows if the width was reduced (assuming dynamic button sizing isn't
feasible)? Then provide vertical window height adjustment (only) as the
vertical scroll bar is provided.

Alternatively remove the buttons Details, Delete, Message, Ping, Query and
provide these functions from Station selection with a right-click? Why
left-click/select button when right-click/select menu option is no less
economical?

Is it possible to save the vertical height of the main window
(non-maximised) when closing?

It's supposed to do that, and the next update will actually do it! ;-)

Thanks Roger!

--
73 - Roger G4ZEC <zec@...>

Version 0.75b cures the map problem I had with 0.74b. I have loaded the same map in both GIF and Bitmap formats and they are identical. My QTH is now back where it should be.

Thank you, Roger, for sorting it out so quickly.

All I want now, is some activity in the South Yorkshire/North Nottingham area. I seem to be the only one using Ui-view. Apart from seeing beacons from my BBS, local nodes and an occasional station, there is nothing. Where are you all? I'm getting fed up looking at an almost empty map!

73 de Keith

keithp@...