Not Showing Up on aprs.fi
N4CVX
my call sign disappeared. I have since tried several different
transceiver, antenna and TNC combinations. I've verified my power
output (5 watts), the antenna SWR, and the signal being sent. I show
up on findu but not on aprs.fi. Other APRS users here in our group
verify that they can see my signal and that my path is good. Am I
somehow being blocked or have been banned? This is extremely serious
business for me since I have had a 50+ year Ham Radio hobby with no
blemishes. Why would I be blocked from aprs.fi?
Heikki Hannikainen
Hi,
No-one is blocked or banned here, at least currently. It's probably a
technical problem, and it's not intentional.
Could you please specify the exact callsign and SSID you're using (is it
N4CVX-9, N4CVX or N4CVX-5? or something else?), and send some testing
packets if you haven't done so in the past day or two.
- Hessu
N4CVX
Here is my path information:
WIDE1-1, WIDE1-2
What I do not understand is how my signal can suddenly just disappear
and never come back -- even after I have used 3 different transceivers
and 3 different APRS devices (Argent Tracker 2; Byonics TT3+ and a
Byonics TT4). In each case, I used the "reset to default" commands to
completely remove all of my previous information from the APRS units,
and when reprogramming them only put in MYCALL N4CVX-9 and PATH
WIDE1-1, WIDE1-2. Something is very strange here. Even more wierd,
is that each of the three units previously worked fine up until about
December 20th, 2009. If you look at the history of N4CVX* you will
see what I mean. There was one path which was seriously incorrect and
I have no idea how that could have been set that way. I have turned
off all "options" such as telemetry, altitude, temperature,
compression and comments, I am still not showing up. I appreciate
your advice.
73's
Dave
N4CVX
N4CVX-9>APOT21,WIDE1*,WIDE2-2,qAR,N5AAA-1:!#<=T38T(c/6KG14.0V > Dave
Mann WCARES 145.21 or 146.52
73's
Dave
> > - Hessu- Hide quoted text -
>
> - Show quoted text -
Justin Pontius
Just my thoughts....
Justin
KD8IAY
--
You received this message because you are subscribed to the Google Groups "aprs.fi" group.
To post to this group, send email to apr...@googlegroups.com.
To unsubscribe from this group, send email to aprsfi+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/aprsfi?hl=en.
N4CVX
have plenty of digi and igates in this area (Brentwood, TN). The only
thing about the WIDE1-1, WIDE1-2 setting is that I was told by someone
here that that setting is not a good one because it causes too much
traffic. Honestly, I wish there were just one setting for everyone
and let it be done at that.
Thanks for your input!
73's
Dave
> > aprsfi+un...@googlegroups.com<aprsfi%2Bunsu...@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/aprsfi?hl=en.- Hide quoted text -
Justin Pontius
Justin
To unsubscribe from this group, send email to aprsfi+un...@googlegroups.com.
Heikki Hannikainen
Hi,
On Tue, 26 Jan 2010, N4CVX wrote:
> Here is my path information:
>
> WIDE1-1, WIDE1-2
The first thing I note is that there should be no space after the comma,
and the second part is a bit strange too.
WIDE1-1,WIDE2-1 would be the correct form for a path.
> WIDE1-1, WIDE1-2. Something is very strange here. Even more wierd,
> is that each of the three units previously worked fine up until about
> December 20th, 2009. If you look at the history of N4CVX* you will
> see what I mean. There was one path which was seriously incorrect and
> I have no idea how that could have been set that way. I have turned
> off all "options" such as telemetry, altitude, temperature,
> compression and comments, I am still not showing up. I appreciate
> your advice.
If we look at the raw packets here:
http://aprs.fi/?c=raw&call=N4CVX-9
The only thing that comes through is the temperature. There's no position
in those packets to show. The path setting in those packets is fine.
You claimed that findu was working, but seems like it's not, only the
voltage is received there, and the last position report is pretty old:
http://www.findu.com/cgi-bin/raw.cgi?call=N4CVX-9&time=1
http://www.findu.com/cgi-bin/find.cgi?call=N4CVX-9
Now, there are two probable options. Either (1) the position is not being
transmitted by the tracker, or (2) it is being filtered by the igate(s) in
your area, so that they're not visible on the APRS-IS for aprs.fi or
findu. The strange detail is that the voltage packets are getting through.
A number of other stations in your area are showing up on aprs.fi.
Would it be possible for you (or another APRS user in your are) to receive
your transmitted raw packets using another tracker or program, and post
copies here so that we could check that they're fine?
- Hessu
Heikki Hannikainen
>> On Tue, Jan 26, 2010 at 11:29, N4CVX <cwo4m...@gmail.com> wrote:
>>> Here is my latest path info taken from findu.com:
>>
>>> N4CVX-9>APOT21,WIDE1*,WIDE2-2,qAR,N5AAA-1:!#<=T38T(c/6KG14.0V > Dave
>>> Mann WCARES 145.21 or 146.52
Please note that the "latest path info" taken from findu.com is over 10
days old: http://www.findu.com/cgi-bin/find.cgi?call=N4CVX-9
Today's packets are here:
http://www.findu.com/cgi-bin/raw.cgi?call=N4CVX-9&time=1
I have a guess... have you tried another GPS receiver? Maybe the tracker
is not receiving the position information from the GPS, and is only
transmitting the voltage because of that. I don't know how the TinyTracker
handles that situation. The GPS cable could have a bad connection, too.
On Tue, 26 Jan 2010, N4CVX wrote:
> So do you think that a setting of WIDE1-1, WIDE1-2 would be best? We
> have plenty of digi and igates in this area (Brentwood, TN). The only
> thing about the WIDE1-1, WIDE1-2 setting is that I was told by someone
> here that that setting is not a good one because it causes too much
> traffic.
WIDE1-1,WIDE2-1 would be good, resulting in a total of 2 digipeater hops.
Please note that it's WIDE2-1, not WIDE1-2. Probably that someone meant to
say that WIDE1-1,WIDE2-2 causes too much unnecessary traffic, and that
WIDE1-1,WIDE2-1 would be better.
> Honestly, I wish there were just one setting for everyone
> and let it be done at that.
Yes, it would be very much preferrable. I think the trackers should not
have such complicated settings. Just a menu item "1 hops", "2 hops" or "3
hops", with the default being 2 hops. And maybe another checkbox for "use
TRACE instead of WIDE". And maybe an advanced menu for the hackers who
want to fiddle with the custom paths. It's way too unfriendly as it is.
- Hessu
N4CVX
Changed out the TinyTracker4 for an Argent Systems FC-301 data radio
(5 watts);
Verified output, frequency, deviation and SWR
Reviewed existing APRS instructions and made change to "WIDE" seting.
Here is a capture from the entire set of instructions which I just
wrote to the FC-301 EEPROM:
1WIREWX OFF
ABAUD 4800
ALIAS 1:N4CVX
ALTITUDE ON
ALTPATH OFF
AMODE AUTO
AUTHLIST
AUTOBAUD ON
AUTOSAVE OFF
BBAUD 4800
BMODE AUTO
CDINVERT OFF
CLIMB OFF
CNTRESET OFF
COMMENT WCARES Responder 145.21 or 146.57
COMPRESS ON
COUNTER OFF
CUSTSYM OFF
DAO OFF
DIGI OFF
DIGIID 1:ON 2:OFF 3:OFF 4:OFF 5:OFF 6:OFF 7:OFF 8:OFF
DUPETIME 15
DOUBLE OFF
EXTSQL OFF
EXTTEMP OFF
FAHRENHT OFF
FILTER OFF
GPSDATA ON
HALFSLOT OFF
HBAUD 1200
HEADERLN ON
HOPLIMIT 1:1 2:0 3:0 4:0 5:0 6:0 7:0 8:0
INTERVAL 100
LVINHIBIT 0
MAXRANGE 0
MONITOR ON
MYCALL N4CVX-9
NICE 1
OUTPUT1 OFF
PASSALL OFF
POSITION GPS
POWER ON
PREEMPT 1:ON 2:OFF 3:OFF 4:OFF 5:OFF 6:OFF 7:OFF 8:OFF
PTTINPUT OFF
PATH WIDE1-1,WIDE2-1
PROPWPT OFF
PWAUTH OFF
QUIET 0
REARM 250
RETRIES 3
RETRYTIME 7
REQALL OFF
RING OFF
SCRIPT OFF
SECRET 0
SHAREDPTT OFF
SLOT 0
SMARTBCON 7 80 900 28 5
SWDCD OFF
STATUS 0
SYMBOL #/
TELEMETRY 0
TEMP ON
TEMPADJ 0
TIMEHMS OFF
TIMESLOT OFF
TIMESTAMP ON
TRACE ON
TXDELAY 25
TXLEVEL 125
TXNOFIX ON
TXONCHG OFF
USEALIAS 1:ON 2:OFF 3:OFF 4:OFF 5:OFF 6:OFF 7:OFF 8:OFF
VELOCITY ON
VOLTAGE ON
WAYPOINTS ON
WPTLEN 9
The system is re-installed and powered up.
I appreciate any assistance in this strange situation.
73's
Dave
N4CVX
James Ewen
> Changed out the TinyTracker4 for an Argent Systems FC-301 data radio
> (5 watts);
Hey, we've got to give you credit... you're consistent. You've got
problems with both the TT4 and OT2! Can you turn off the compression
on the OT2 just for testing. Makes it easier on us to see the human
readable data. I'm trying to figure out why the OT2 packets are still
registering as bad.
You've got timestamps, voltage, GPS, and temp reporting all turned on,
and comment text on every transmission. All things than make your
packets larger than necessary, but not the source of your problems. If
you turn those all off, then it makes the packet as small and simple
as possible, which means less data to analyse, and less data that
might be causing an issue. Again, these probably aren't the source of
the issue, but if you eliminate all the extraneous stuff, you're only
left with the source of the problem.
N4CVX-9>APOT21,NT4UX-3*,WIDE1*,WIDE2-1,qAR,N5AAA-1
N4CVX-9>S6PP7S via NOLEN*,WIDE12*,NULL,NULL,qAR,N5AAA-1
The WIDE12*,NULL,NULL in the path is something really wonky... The
last raw packet was the first one above, but aprs.fi's info page shows
the last path as the second entry. Where's that WIDE12* coming from,
and what's with the NULL entries?
Hessu might have to dig a bit. Is the issue in the raw packet where we
don't see it, or is there some silly bug happening in Hessu's code?
You've got a good head scratcher happening!
>> > Honestly, I wish there were just one setting for everyone
>> > and let it be done at that.
Well, to make one single setting work for everyone, we'd have to
figure out how to make everyone operate in the same manner. The basic
generic outgoing path setting that will work for *most* trackers is
WIDE1-1,WIDE2-1. Those flying in the air are asked to use a shorter
path. Those way out in the boonies might need a longer path.
The idea is to be able to have a generic path that will work
everywhere, but it is not possible to create a perfect network that
looks exactly the same everywhere.
Start with the generic setting and modify IF required.
James
VE6SRV
N4CVX
head-scratcher. Notice that no-place in the OT2 does it say anything
about "NULL" --- I am sure I don't know where that comes from.
\
Tomorrow AM I will turn off the extraneous stuff and then fire up the
system at about 7:30am local time. Then I'll be driving around for
most of the day, so we will see what that test looks like.
If necessary, I can mount up to four trackers with transmitters in the
same vehicle at the same time all programmed with exactly the same
settings; a TT2 (The FC301 device), a Byonics TT4 and two separate
Byonics TT3+ devices, each operating independently of each other. All
with similiar 5-watt transmitters and all with 1/4 wave ants. Just as
soon not do that but could if necessary.
73's
Dave
N4CVX
On Jan 26, 5:18 pm, James Ewen <ve6...@gmail.com> wrote:
James Ewen
> OK James, thanks for the most excellent reply. You're right, it is a
> head-scratcher. Notice that no-place in the OT2 does it say anything
> about "NULL" --- I am sure I don't know where that comes from.
That's probably not coming from the OT2, nor the TT4, at least
probably not recently.
Last position: 2009-12-20 10:35:48 UTC (37d 17h32m ago)
2009-12-20 04:35:48 CST local time at Brentwood Estates, United States [?]
That's probably why the WIDE12*,NULL,NULL packet shows up on the info
page, but not in the raw packets.
Another interesting thing is that aprs.fi knows that you have been
sending packets, but it reports that no one has heard you...
Packets transmitted: 104 over the last 48 hours, heard on radio by 0
known stations, 0 known iGates
Hessu has to be happy since you're really torture testing the website
with some really funky data. Making the site work with regular old
packets is easy... making it work with wacky packets takes work. We'll
have to see what he has to say.
> Tomorrow AM I will turn off the extraneous stuff and then fire up the
> system at about 7:30am local time. Then I'll be driving around for
> most of the day, so we will see what that test looks like.
Uncompressed data, with all the extras turned off will make it easier
to try and figure out what's happening for me at least.
> If necessary, I can mount up to four trackers with transmitters in the
> same vehicle at the same time all programmed with exactly the same
> settings; a TT2 (The FC301 device), a Byonics TT4 and two separate
> Byonics TT3+ devices, each operating independently of each other. All
> with similiar 5-watt transmitters and all with 1/4 wave ants. Just as
> soon not do that but could if necessary.
Oh that would really make a mess, especially when all 4 would be
reporting under the same callsign. The strangest part is that you're
having issues with both a TT4 and the OT2. Not the same issues, but
issues none the less.
James
VE6SRV
Heikki Hannikainen
> Another interesting thing is that aprs.fi knows that you have been
> sending packets, but it reports that no one has heard you...
>
> Packets transmitted: 104 over the last 48 hours, heard on radio by 0
> known stations, 0 known iGates
The problem is that the position in those packets is not decoded, the
packets are reported as invalid for some reason. If there's no decoded
position, the "heard" list won't update, since it can't calculate the
distance.
"Stations which heard OH8HBG-9 directly on radio over the last 48 hours"
should actually read
"Stations which heard position packets from OH8HBG-9 directly on radio
over the last 48 hours"
since it doesn't care about anything but position packets. I'll have to
update that.
>> Tomorrow AM I will turn off the extraneous stuff and then fire up the
>> system at about 7:30am local time. Then I'll be driving around for
>> most of the day, so we will see what that test looks like.
>
> Uncompressed data, with all the extras turned off will make it easier
> to try and figure out what's happening for me at least.
>> If necessary, I can mount up to four trackers with transmitters in the
>> same vehicle at the same time all programmed with exactly the same
>> settings; a TT2 (The FC301 device), a Byonics TT4 and two separate
>> Byonics TT3+ devices, each operating independently of each other. All
>> with similiar 5-watt transmitters and all with 1/4 wave ants. Just as
>> soon not do that but could if necessary.
>
> Oh that would really make a mess, especially when all 4 would be
> reporting under the same callsign. The strangest part is that you're
> having issues with both a TT4 and the OT2. Not the same issues, but
> issues none the less.
Please just run the TT2/FC301.
- Hessu
Heikki Hannikainen
Dave,
On Tue, 26 Jan 2010, N4CVX wrote:
> SYMBOL #/
A-ha, that's not a valid symbol. /# would be a digipeater. Try setting
that to "SYMBOL />" for a car. The first character needs to be either / or
\, or an upper-case letter or a number (for an overlay).
The APRS packet parser here cannot figure out that the packet is a
position packet, because the leading character after the timestamp does
not fit within the required range for a compressed packet.
2010-01-27 08:18:34 UTC:
N4CVX-9>APOT21,NT4UX-3*,WIDE1*,WIDE2-1,qAR,N5AAA-1:/270818z#<;H[8T(b/6!G/A=00072512.2V
-62C HDOP00.9 SATS09 WCARES Responder 145.21 or 146.57 [Invalid packet]
- Hessu
N4CVX
have changed the beacon text to read "APRS.FI Test. And changed the
SYMBOL to / >
Let's see what happens now.
73's
Dave
Heikki Hannikainen
> OK, I am starting out this morning with all options turned off. I
> have changed the beacon text to read "APRS.FI Test. And changed the
> SYMBOL to / >
Seems to work now with the fixed symbol. I suppose you can now switch back
to compressed mode to make the packets a bit smaller.
> On Jan 27, 2:39 am, Heikki Hannikainen <he...@hes.iki.fi> wrote:
>> On Tue, 26 Jan 2010, N4CVX wrote:
>>> SYMBOL #/
>>
>> A-ha, that's not a valid symbol. /# would be a digipeater. Try setting
>> that to "SYMBOL />" for a car. The first character needs to be either / or
>> \, or an upper-case letter or a number (for an overlay).
- Hessu
N4CVX
watching the raw packets on aprs.fi, and notice that they are pretty
ordinary so far. We can see what happens later today and tomorrow.
73's
Dave
N2ERK
I am having the same problem with a Yeasu VX-8R. I also see
conflicting data between various APRS-IS sites, some are a day or more
behind in showing locations.
Thanks,
Eric
N2ERK
On Jan 26, 11:22 pm, James Ewen <ve6...@gmail.com> wrote:
Heikki Hannikainen
Hello,
On Sat, 20 Feb 2010, N2ERK wrote:
> I am having the same problem with a Yeasu VX-8R. I also see
> conflicting data between various APRS-IS sites, some are a day or more
> behind in showing locations.
Like the group's front page (http://groups.google.com/group/aprsfi)
requests: If you're having a problem, please describe it with as much
detail as possible.
Please provide links to the sites / pages with the conflicts, and describe
the conflicts in more detail. You also need to specify the exact time when
the problem was seen, and preferably it should be within the past couple
days so that the raw packets can be inspected. It's hard for us to guess.
- Hessu
James Ewen
> I am having the same problem with a Yeasu VX-8R. I also see
> conflicting data between various APRS-IS sites, some are a day or more
> behind in showing locations.
You're showing up on aprs.fi... I've pulled up your location
information. You are near Riverdale, NJ.
One thing that one has to remember is that all of the APRS display
websites can only display the information that they are provided.
There are a lot of bits of hardware and software playing with the data
from the time you send it from your radio until it gets saved in the
website's database.
If we have a look at the data that Hessu has saved in the database, we
can immediately see something strange happening.
2010-02-19 14:10:27 MST:
N2ERK>4Q0P3W,WB2FTX-15,WIDE1*,WIDE2-2,qAR,N5CAT-13:`f*jl!yj/`"5<}VX-8R
_
2010-02-19 14:10:27 MST:
N2ERK>4Q0P3W,WB2FTX-15,WIDE1,K2MAK*,WIDE2-1,qAR,N2MH-12:`f*jl!yj/`"5<}VX-8R
_
2010-02-19 14:12:27 MST:
N2ERK>4Q0P3W,WB2FTX-15,WIDE1*,WIDE2-2,qAR,N5CAT-13:`f*jl!yj/`"5<}VX-8R
_
These three packets all appear to be carrying the exact same
information. The first two have identical timestamps. The APRS-IS
i-gates are supposed to filter out duplicates so that this doesn't
happen. Is there a hidden character or something making one packet
different than the other? The third packet is outside of the 30 second
anti-dupe window, so it might just have been another packet that you
sent. There are issues with some i-gates delaying packets, but
N5CAT-13 had already forwareded the packet 2 minutes earlier.
2010-02-19 16:07:16 MST:
N2ERK>4Q0P3V,WB2FTX-15,WIDE1*,WIDE2-2,qAR,N5CAT-13:`f*kl cj/`"55}VX-8R
_
2010-02-19 16:07:16 MST:
N2ERK>4Q0P3V,WB2FTX-15,WIDE1,K2MAK*,WIDE2-1,qAR,N2MH-12:`f*kl
cj/`"55}VX-8R _
2010-02-19 16:09:17 MST:
N2ERK>4Q0P3V,WB2FTX-15,WIDE1,K2MAK*,WIDE2-1,qAR,N2MH-12:`f*kl
cj/`"55}VX-8R _
Again, the same issues, but the third packet is 121 seconds later, and
through N2MH-12. I would suggest that you probably have the VX-8 set
to TX every 2 minutes, and the third packet is another new packet
being sent with the same information encoded. That still doesn't
explain the two copies with identical time stamps.
2010-02-20 12:31:16 MST:
N2ERK>4P5Y1R,WB2FTX-15,WIDE1*,WIDE2-1,qAR,KC2DHU:`f.2l!Nj/`"4U}VX-8R _
2010-02-20 12:31:16 MST:
N2ERK>4P5Y1R,WB2FTX-15,WIDE1*,WIDE2-1,qAR,K2MHV-6:`f.2l!Nj/`"4U}VX-8R
_
And again... but through two totally different i-gates... anyone see
similar issues with other VX-8R users? Maybe it's something the VX-8R
is doing... I can't see what it would be, but it is strange that 4
different i-gates would exhibit the same issues.
Spew more packets out, and then point us at the issues that you are seeing.
James
VE6SRV
John
My friend W5BIY also shows up okay on Findu but not on aprs.fi. His
is using a Tinytrac3 with the call W5BIY-9
Thank you
John
Heikki Hannikainen
Hi,
On Sun, 21 Feb 2010, John wrote:
> My friend W5BIY also shows up okay on Findu but not on aprs.fi. His
> is using a Tinytrac3 with the call W5BIY-9
If you take a look at the raw packets:
http://aprs.fi/?c=raw&call=W5BIY-9&limit=50
Every position packet is shown in red and it says "Invalid symbol table or
overlay". So, the symbol configuration is wrong on that tracker - the
first character of the symbol should be either / or \, or a number or a
character (for an overlay). Please see the following page for details:
http://wa8lmf.net/aprs/APRS_symbols.htm
Findu.com might accept these packets, but aprs.fi doesn't, because they're
broken.
- Hessu
John W. Benedict
I don't know why I never checked or even looked at his raw packets...
Again thank you
John
-.- . ..... .-. ...
Hi,
http://aprs.fi/?c=raw&call=W5BIY-9&limit=50
http://wa8lmf.net/aprs/APRS_symbols.htm
- Hessu
--
James Ewen
> Thank you,
> I don't know why I never checked or even looked at his raw packets...
> Again thank you
It's hard to tell looking at the raw packets as they are compressed
and not easy to decode. Hessu's site does the hard work for you.
James
VE6SRV
Heikki Hannikainen
> It's hard to tell looking at the raw packets as they are compressed
> and not easy to decode. Hessu's site does the hard work for you.
There's still room for improvement:
- the raw packets should be stored for a longer time
- there should be an online decoder for parsing the raw packets
- there should be a "show binary packets in hex" option to see / download
the packets with all the space characters etc... now it just shows the
unprintable packets in hex
- Hessu
James Ewen
> There's still room for improvement:
Yeah, but the guy that codes the site that we get free access to does
such a good job that it is difficult to justify pestering him for more
and more features.
> - the raw packets should be stored for a longer time
I wouldn't complain about having a little more history.
> - there should be an online decoder for parsing the raw packets
That would be great, especially for situations like the last one.
> - there should be a "show binary packets in hex" option to see / download
> the packets with all the space characters etc... now it just shows the
> unprintable packets in hex
That would be a good option as well. I'd like to see if there's
anything in those packets that would allow the APRS-IS antidupe
routine to allow them both in there.
I'd like to see the comment and status text, as well as the raw
packets printed in a preformatted font. HTML likes to treat multiple
space characters as a single character. I use a lot of double spaces
to format the text to fit the D7 and D700 screens, but trying to
explain that to people when they can't see them on the web makes them
all confused. Using preformatted text allows these extra spaces to be
seen.
It's also nice to be able to see just what these extra spaces do when
trying to fit to the 10X10X7 screen format. The oaprs.net search page
is the only place that I know of that shows a simulated screen shot as
seen on the Kenwood radios displays.
James
VE6SRV
David Fraser
I've noticed one or two digis using UIDIGI that seem to be digipeating a WIDE1-1 in a path incorrectly (but I might be wrong of course). This is how ZL2IC-9 shows up on the 'info' screen:
Last path: ZL2IC-9>APT312 via ZL2KS-3*,WIDE1,WIDE2-2,qAR,ZL2FX-5 (Good path!)
Note that the asterisk is on the digi callsign (ZL2KS-3) instead of the WIDE1.
If I am interpreting this correctly, it means that ZL3KS-3 digi has not handled the WIDE1-1 correctly. If so, would it be helpful if aprs.fi was to display a 'caution' or something to say that it thought that something dodgy might be happening?
73, David ZL3AI.
Ham radio stuff: http://qsl.net/zl3ai
All other stuff: http://soaringkiwi.weebly.com
Phone: (03) 314 6825
Cellphone: 021 294 0916
Skype: david.zl3ai
Cap Pennell
but not operating WIDE1-1 correctly) can be the outcome from other kinds of
misconfigured digipeaters too, as well as the UIDIGI firmware TNC
digipeaters, including early versions of KPC-3 TNC digipeaters. The
solution to repair most of such misconfigured digipeaters is to have added
WIDE1-1 (specifically) to the UIDigi setting within the digipeater's TNC.
73, Cap KE6AFE
> -----Original Message-----
> From: apr...@googlegroups.com [mailto:apr...@googlegroups.com] On
Phillip
|
Hi David and Cap
The problem has been resolved
73 Phillip
ZL2TZE
-------Original Message------- |
--
You received this message because you are subscribed to the Google Groups "aprs.fi" group.
To post to this group, send email to apr...@googlegroups.com.
To unsubscribe from this group, send email to aprsfi+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/aprsfi?hl=en.
|
|
|
Heikki Hannikainen
Hi,
On Sat, 6 Mar 2010, David Fraser wrote:
> Last path: ZL2IC-9>APT312 via ZL2KS-3*,WIDE1,WIDE2-2,qAR,ZL2FX-5 (Good path!)
>
> Note that the asterisk is on the digi callsign (ZL2KS-3) instead of the
> WIDE1.
>
> If I am interpreting this correctly, it means that ZL3KS-3 digi has not
> handled the WIDE1-1 correctly. If so, would it be helpful if aprs.fi was
> to display a 'caution' or something to say that it thought that
> something dodgy might be happening?
Well, there must be an asterisk (has digipeated) bit on the digi callsign
ZL2KS-3, so that's not an error.
I suppose there should also be a star on WIDE1 since that path element is
fully used, too, but that's not a very bad failure since no-one will
digipeat based on the WIDE1 element. The next digis will continue by
decrementing WIDE2-2 to WIDE2-1. The missing * is mostly a cosmetic bug.
It could be useful to have a warning for the missing *, but it's pretty
difficult to place the warning in the correct place - it should be on the
digipeater's info page (ZL2KS-3, not ZL2IC-9). And often it's hard to
figure out which digipeater is having the problem. A received path
"ZL2KS-3*,WIDE1,WIDE2-2" could have originally been (hypothetically)
"WIDE1-1,WIDE1-1,WIDE2-2", and aprs.fi has no way to tell for sure what it
was. Maybe ZL2KS-3 was a dumb fill-in digi which replaced WIDE1-1 with
ZL2KS-3* and then there was a second digipeater which just decremented
WIDE1-1 to WIDE1 without inserting a callsign (there are plenty of those
over here, unfortunately).
It's possible to make guesses, but it's hard to place the blame accurately
on the right station, without actually listening to the RF traffic
locally. I don't want to blame digipeaters based on guesses.
- Hessu
Cap Pennell
"ZL2KS-3*,WIDE1,WIDE2-2" was only that _then_ the WIDE2-2 portion could not
be acted upon by any other digipeaters.
I'm pleased to hear that ZL2KS-3 digi has already been repaired.
Now, I see it produces "ZL2KS-3,WIDE1*,WIDE2-2" which does allow further
digi hops.
73, Cap
> -----Original Message-----
> From: apr...@googlegroups.com [mailto:apr...@googlegroups.com] On