| |
ZL3AI > APRDIG 28.01.07 14:17l 384 Lines 14956 Bytes #999 (0) @ WW
BID : 9631-ZL3AI
Read: GUEST
Subj: [APRSSIG] Vol 31 #30, 2/3
Path: DB0FHN<DB0FOR<DB0SIF<DB0EAM<DB0NOS<DB0EA<DB0RES<F5GOV<F4BWT<TU5EX<
IW2OAZ<ZL2BAU
Sent: 070128/0611Z @:ZL2BAU.#79.NZL.OC #:29603 [Waimate] $:9631-ZL3AI
From: ZL3AI@ZL2BAU.#79.NZL.OC
To : APRDIG@WW
Message: 12
Date: Thu, 25 Jan 2007 13:58:31 -0800
From: "VE7GDH" <ve7gdh_at_rac.ca>
Subject: Re: [aprssig] Garmin IMG Fn ?
Clem NR3U wrote...
>Can anyone help me relate a Garmin.IMG file name to a city or state map
>that I may want to use?
I don't know what the Garmin.IMG file is, but I would assume that it's only
usable in the Garmin program that you are using. However you could grab one
or more screenshots of the map and make note of the lat/long in the
corners, or two points near the corners and calibrate them as a static maps
for UI-View.
73 es cul - Keith VE7GDH
--
"I may be lost, but I know exactly where I am!"
------------------------------
Message: 13
Date: Thu, 25 Jan 2007 17:06:26 -0500 (EST)
From: "William McKeehan" <mckeehan_at_mckeehan.homeip.net>
Subject: RE: [aprssig] Local Repeater Displays on Mobiles
I don't really have an opinion about how this should work, but in thinking
about using CALLSIGN-R I see an issue.
Where I am, there are a number of repeaters that would have the same
callsign as they are controlled by the same owner; not necessarily in the
same location, so you could easily have multiple objects with the same name
as you drive across East TN.
Would this not cause more (at least similar) problems than using the
frequency for the name of the object?
--
William McKeehan
------------------------------
Message: 14
Date: Thu, 25 Jan 2007 22:39:42 -0000
From: "Dave Baxter" <dave_at_emv.co.uk>
Subject: [aprssig] 220KISS
Hi All...
Does anyone have any informaton re the KISS only rom image "220KISS" for
the Pac-Com TNC-220 ?
I have just tried it, and though it receives well, it often transmit's a
blank signal, that is, it keys the radio, but send no audio, that about 50%
of the time. When it does transmit audio, often it's truncated at the
begining of the packet. When it works though, the packet and data are
good.
The hardware is fine, the TNC-220 and radio (FT2700RH) are time prooved and
work well.
However due to a strange issue between UiView and the original TNC firmware
1.1.5 and 1.1.6 and it's KISS implementation, I was getting overlong
transmit preambles, like at least one second! But the data payload was
good. Hence at someone else's recomendation, I went looking for this.
Google for "220KISS" (no quotes) and you'll find it.
In regular packet mode with the original firmware, the TNC works OK, no
problems at all.
So, looks like a bug in the 220KISS code? Anyone know of a copy of the
sources, I have Z80 cross assemblers to hand.
I believe it was in part crafted by G8BPQ. Anyone have any contact details
for him?
It may be a "Bit Old" though.. V.32 26MAR 87 can be seen in the rom
image starting at address 0003. The size of the image is 2k (2048 bytes)
Anyone got a newer version?
Cheers...
Dave G0WBX.
------------------------------
Message: 15
Date: Thu, 25 Jan 2007 17:46:19 -0500
From: "Robert Bruninga" <bruninga_at_usna.edu>
Subject: RE: [aprssig] Local Repeater Displays on Mobiles
>...in thinking about using CALLSIGN-R I see an issue.
>Where I am, there are a number of repeaters that would
>have the same callsign as they are controlled by the
>me owner; not necessarily in the same location, so you
>could easily have multiple objects with the same name
>as you drive across East TN.
Yes, this is just one of the many reasons why using voice repeater
callsigns as an identifier on APRS makes no sense. Besides, I don't know of
anyone that knows various local repeaters by their callsign, most everyone
I know refers to repeaters by their frequency. About the only people who
know the repeater callsign are the locals, and this travelers repeater
frequency info is not intended for them.
Not counting the unworkable identification by repeater callsign, there have
been four recommendations on the proper format for displaying these
repeater frequencies on the front panel of mobile radios:
1) OBJ-with PHG,
2) OBJ-with RNG,
3) 3rdPRTY-with PHG
4) 3rdPRTY-with RNG
and the only one that seems to work reliably on all versions of the D7 and
D700 and HAMHUD is the 3rdPARTY with PHG as shown here:
BT }146.760->APOBJ:!DDMM.hhN/DDDMM.hhWrPHG5320 PL 107.3 Net Tu 9PM
So that seems to be the best all around. If people want their local object
to be unique globally, then they may add a byte on the end of the object
(146.760-X) to make it one of 36 different unique objects.
Bob, WB4APR
------------------------------
Message: 16
Date: Thu, 25 Jan 2007 22:49:24 -0000
From: "John Wiseman" <john.wiseman_at_ntlworld.com>
Subject: [aprssig] RE: 220KISS
A non-text attachment was scrubbed...
------------------------------
Message: 17
Date: Thu, 25 Jan 2007 22:57:00 -0000
From: "Dave Baxter" <dave_at_emv.co.uk>
Subject: RE: [aprssig] APRS telemetry and the PIC 16F877A
Easy!... (Reletively at least!)
Google for SOTT, or "Son of Tiny Trak" The code ports easily to the F877,
and as it's in C, is relatively easy to manipulate. Somewhere I have one
such already programmed. I know some people were also looking into using
the PWM system to output the tones. Likewise, the PWM capture logic to
receive and decode them, for all I know they got it working, or maybe not.
However, as above, the SOTT code goes easily into the F877. If I can do
it, anyone can!...
The one nice thing about PIC's, is for the same series of CPU, (8 or 16
bit) the code changes very little between devices in the same family. Most
is figureing out the config settings, and port naming conventions.
Sometimes you can have just too many IO functions to choose from. The F877
is one such chip. Just because it has ASYNC/SYNC serial IO, doesnt mean
you *have* to use it. Hence, code from lesser chips that do all that bit
by bit (Bit/Bang) will still run just fine.
If you go and download the MPLAB toolsuit (for free!) and the free but
limited version of HiTech C compiler, you'll be OK. Mind you, by now I
expect the code has been ported to one of Microchip's C compilers. There
are dozens of others of course.
Other choices, there are several PIC based TNC's about, with freely
available source code, both C and assembler, also both regular packet, and
APRS versions too.
There is nothing wrong with the Atmel chips, but the CPU architecure you
could argue harks backwards in time, though they can be very low power, and
very fast running! And of course if you have already worked with the Intel
805x series chips, the learning curve could be relatively shallow.
PIC's and RISC archetcture, looking forward by comparison? You choose,
based on what you have, and what you can get for free!
Have Fun..
Dave G0WBX.
------------------------------
Message: 18
Date: Fri, 26 Jan 2007 09:54:45 +1100
From: Ray Wells <vk2tv_at_exemail.com.au>
Subject: Re: [aprssig] 220KISS
Hi Dave
The binary used to ship with BPQ408. It's along time since I used BPQ
but I vaguely recall a couple of versions of KISS for the TNC220 (was
JKISS the other version?). What I do recall is that my TNC220 NEVER gave
reliable results, regardless of the EPROM installed, and it's been
gathering dust for near 15 years.
The version of the binary I have is the same as yours.
Ray vk2tv
------------------------------
Message: 19
Date: Thu, 25 Jan 2007 14:59:19 -0800
From: "Scott Miller" <scott_at_opentrac.org>
Subject: RE: [aprssig] APRS telemetry and the PIC 16F877A
The OpenTracker code's also out there (it does PWM audio synthesis) and has
the advantage of not requiring any special hardware to do the programming.
The configuration program will take .s19 files straight from the linker and
upload them to the MCU, remapping interrupt vectors on the fly for
compatibility with the bootloader. You just compile and upload, no need to
pull the chip or switch cables.
I can't remember now which tool it was I used, but it was one of the 'C'
freebies for the PIC. It didn't support any array size larger than 256
elements, and it had no support for data structures at all. Really
frustrating for someone who's used to ANSI C. (got my copy of K&R 2nd
edition here on the desk)
Scott
N1VG
------------------------------
Message: 20
Date: Fri, 26 Jan 2007 09:15:52 +1100
From: "Andrew Rich" <vk4tec_at_tech-software.net>
Subject: RE: [aprssig] APRS telemetry and the PIC 16F877A
A non-text attachment was scrubbed...
------------------------------
Message: 21
Date: Thu, 25 Jan 2007 18:33:24 -0500
From: "Robert Bruninga" <bruninga_at_usna.edu>
Subject: RE: [aprssig] Local Repeater Displays on Mobiles
>>>(Bob, if you are doing lookups while you are in
>>>motion behind the wheel, you are spending way
>>>too much time with your eyes off of the road).
>>
>>If the object name is the freq, as I propose, then
>>one does not have to do any "lookup".
>
>But you do have to do a lookup because you have no idea
>where that repeater is or what tone it uses without
>doing a lookup.
No, my proposal does not require any lookup most of the time. When I am
driving through an area and am wondering what the local voice repeater
frequency is, I don't need to know the PL nor do I need to know where it is
in order to listen to it. And the object only shows up on my radio front
panel (direct) when I am in range. If I am in range, I don't care where it
is. Now, after seeing the frequency show up on my radio front panel LIST
and listening to it for a while, then, if I want to talk, I will have to
hit the OK button to see its PL tone if any. But most of the time I just
want to monitor first. And if it does not need a PL, then I never have to
do a lookup.
>And if you are staring at the display to see a momentary
>flash of the information (which is all you get around
>here), then yes you are spending too much time looking
>at the display.
Yes, that is exactly the problem with the CALLSIGN-ID method in your area
(around there). You cannot see the frequency unless you happen to watch
the screen when it first flashes up. This diverts the driver's attention
and is not safe. That is why we don't recommend that method.
The FREQ-ID method I propose, displays the frequency on the front panel
station LIST all the time. If the driver has pressed his LIST button once,
from then on, for the rest of the trip, the 5 most recent objects/stations
will always be on his front panel LIST. If one of them is a voice repeater
frequency, then that user can see it at any time hand's free. Without
being interrupted by the flash and without having to push any buttons to
read it.
>>We recommended putting the ER or IP in front of the
>>[ECHOlink and IRLP object names so that when truncated on
>>a 6 character GPS map, then the more important node number
>>would still show on the map. Thus we get ER-123456 for
>>ECHOlink and IRLP-8080 for IRLP and these show on the
>>worst-case-6-byte GPS map as 123456 and P-8080.
>
>It is not consistent because there are frequencies being
>displayed with no concept as to what that frequency is
>(yes, people can guess that it is a voice repeater)
>especially if everyone plays with it to make sure they
>don't clobber somebody due to propagation.
Yes, that is exactly why we are proposing this standard for voice repeater
frequency display on APRS. If all voice repeater frequenceis are
transmitted in this manner, then we won't have any ambiguity.
>[regarding object-permanence:]
>You do not understand APRS-IS and how it works. You do
>not know how the servers or database clients work.
But I know how they -are-supposed-to-work-. I know that the APRS spec
specifically states that the originating callsign of an OBJECT should be
retained along with the object itself so that ownership of an object is
unambiguous. This is required for data integrity of the APRS system. If
clients have not properly implemented OBJECTS according to the spec, then
they need to be fixed.
>Please do not state "Only a few lines of code change"
>when you don't have a clue. Suffice it to say, APRS-IS
>servers and database servers are not going to change
>for this.
That's too bad. Here we have an opportunity to provide for object
permanence in APRS, and I think we should consider it.
>This is silly. You aren't listening and aren't
>considering anything I have said (all you have done
>is attempt to justify your own position).
I am surprised to see you say that. I have considered all of your inputs,
and have openly discussed their merits and have used them to better refine
my proposal over the last week.
1) I took your input that you want to see these things on the APRS-IS, so I
came up with three backwrd compatible methods to make the objects unique.
a) Permanent object format. b) Permanent 3rd party format, c) FFF.FFF-X
format.
2) I took your input about the RNGxxxx as the better way to display
repeater range on these objects and added it to the recommendation. That
is, until it was tested and found not to work on the D7 and D700.
3) I took your input about using TCPIP* to prevent these objects from
entering the APRS-IS. But then it was incompatible with recommendation
number 1, so it was not used.
So I value your input and used all of it that could work.
>Personally, I am not going to start using frequencies for
>object names just because you think it is a good idea with no
>consideration of the negatives.
I haven't seen any negatives, that have not been solved with the current
recommendation and with inputs from others as to what works and what
doesn't.
>So this discussion, IMO, is dead. At least I am done with it.
That is too bad. It is really a great concept and makes the APRS mobile
travler enjoy his trip by seeing the operating frequency of the locally
recommended repeater show up on this radio front panel hands-free. And
this only shows up when he is in range. Thus it is useful, pertinent,
timely, real-time information, which is exactly what APRS is all about. I
think it is a great feature for APRS mobiles. And is trivial to implement
by any local sysop in his digipeater.
Bottom line, this is the best recommendation that has evolved through
inputs on the APRSSIG. This is easily implemented in the BText of APRS
digipeaters (using KPC-3 type command sets) to send out these local direct
voice repeater objects. It is the most workable of all considered and
tested:
BT }146.760->APOBJ:!DDMM.hhN/DDDMM.hhWrPHG5320 PL 107.3 Net Tu 9PM AARC W3VPR
B E 10
UNPROTO APNxxx <== where XXX is the version ID for your digipeater.
Its in my digi and looks pretty good on the mobile D7 and D700 displays.
I'm sorry that the RNGxxxx didn't work. It seems not to be parsed into the
D7/D700 display field set aside for that purpose. I agree that it was
better for the mobile operator, but since it is not showing up in the PHG
field like it is supposed to, it therefore consumes 7 bytes out of the
available 20 which are better used for other things...
Bob, WB4APR
------------------------------
Read previous mail | Read next mail
| |
