Packet path and line draw

[OK1ALX]

Hello

Sometimes, iam driving around to test the digi coverage by setting the path in radio with the first hop corresponding to testing digi, like this: DIGI_CALL,WIDE2-2 ...
And i see two different handling of such data on aprs.fi.
First, the heard map shows correctly the squares at places where it really heards the packets.
Second, the normal map shows the lines of the packet path, red for normal hop, violet for hop heading to igate. Here, the line is shown for the first hop (the digi i have on the first place in path), even if digi doesn't hear&repeat the packet. So it looks like it goes over the digi everytime (since the packet path is set as described above).
The key thing is the star in the packet path, which should be used to recognize the real packet track. Looks like this works on heard map, but not on normal map :-)

See the examples of what iam talking about:

The packet goes directly to igae OK1KHL-1, not even touching the OK1ALX-2 digi:
2012-03-03 21:05:36 CET: OK1ALX>UP0R15,OK1ALX-2,WIDE2-2,qAR,OK1KHL-1,T2CZECH:`+`o |n>/]"6@}438.900MHz op.Libor=
- on the map, the line is drawn trough the digi (nonexisting hop)

This is the path, going through multiple, digis, including OK1ALX-2 digi and ending in OE3XOC-5 igate. All the touched digis are market with star :
2012-03-03 21:06:10 CET: OK1ALX>UP0R15,OK1ALX-2*,OE3XHR*,OE3XKR*,WIDE2*,qAR,OE3XOC-5:`+`o |n>/]"6@}438.900MHz op.Libor=
- the line is drawn as it should be

So it looks like the normal live map shows incorrect informations in the ballon (missing stars in path) and then draw not acurate lines towards internet gate, what do you think?

Best Regards,
Libor, OK1ALX

[Heikki Hannikainen]

Hi,

On Tue, 8 May 2012, OK1ALX wrote:

> Second, the normal map shows the lines of the packet path, red for normal hop,
> violet for hop heading to igate. Here, the line is shown for the first hop
> (the digi i have on the first place in path), even if digi doesn't hear&repeat
> the packet. So it looks like it goes over the digi everytime (since the packet
> path is set as described above).

Yeah, you're right. The background for this is the fact that the backend
code precompiles references to all of the known callsigns in the path
(even if the callsigns didn't actually digi the packet). This is right and
well, since it's good to make all of the callsigns clickable links in all
of the views, and the links are quickly generated using those precompiled
references.

The bug is that the path line is drawn via all known stations referenced
in the path without paying attention to the "has digipeated" info. The
"has digipeated" information is not currently available to the Javascript
user interface code that draws the line in question. I'll see what I can
do to fix that.

You're the first one to complain, since it's quite rare to do what you're
doing (configuring specific digipeaters).

When I fix this, some other people will probably come complaining. If I
remember right, some popular digipeater doesn't set the "has digipeated"
bit in some situation when replacing a path element with it's own
callsign.

I'll come and test your digipeater paths in Prague in a week (Sat-Tue
19-22th).

> The packet goes directly to igae OK1KHL-1, not even touching the OK1ALX-2
> digi:
> 2012-03-03 21:05:36 CET:OK1ALX>UP0R15,OK1ALX-2,WIDE2-2,qAR,OK1KHL-1,T2CZECH:`+`o |n>/]"6@}438.900MHz op.Libor
> =
> - on the map, the line is drawn trough the digi (nonexisting hop)

- Hessu

[OK1ALX]

Hi

When you say that, i can see it now. The rf monitor on Digi_Ned console shows the star next to the digipeater calsigns whis has digipeated. But if i look in the rf monitor on UI-View with TNC connected directly, then i see star only at last element in digipeated path. But if i connect UI-View through the AGW PE, then i can see the stars at every element which has digipeated.
Which is kind of strange, it means that there are different softwares, with different handling? Thats weird.

If you don't get this information correct through APRS-IS, then i can understand you cannot process the code correctly. :-(


Anyway, you will be welcome in Prague and if you'll have a spare time, we could meet if you like.


Libor, OK1ALX


Dne středa, 9. května 2012 9:25:55 UTC+2 Heikki Hannikainen napsal(a):

[Heikki Hannikainen]

That's a completely different thing, there are variations in the monitor
format. Some TNCs show a star on each used path component, some TNCs show
a star on all used path component, and the first thing aprs.fi does (when
decoding that) is adding the star on all components before the one with
the star.

> > 2012-03-03 21:05:36CET:OK1ALX>UP0R15,OK1ALX-2,WIDE2-2,qAR,OK1KHL-1,T2CZECH:`+`o |n>/]"6@}438.900MHz op.L

> ibor
> > =
> > - on the map, the line is drawn trough the digi (nonexisting
> hop)
>
>    - Hessu
>

> --
> You received this message because you are subscribed to the Google Groups
> "aprs.fi" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/aprsfi/-/JYHHxi_WwQcJ.
> 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.
>
>

- Hessu

[OK1ALX]

Ok, so it looks like this has no solution, right? :)

Dne středa, 9. května 2012 10:54:55 UTC+2 Heikki Hannikainen napsal(a):

> aprsfi+unsubscribe@googlegroups.com.

[Heikki Hannikainen]

On Sat, 12 May 2012, OK1ALX wrote:

> Ok, so it looks like this has no solution, right? :)

Well, as I said earlier (quoted below), "I'll see what I can do to fix
that". :)

How about I come to Prague to discuss this in more detail on Saturday
evening, perhaps over a beer? Sunday is busy, and so is monday (scheduled
a meeting with the giraffes).

> > aprsfi+un...@googlegroups.com.

> > For more options, visit this group at
> > http://groups.google.com/group/aprsfi?hl=en.
> >
> >
>
>    - Hessu
>

> --
> You received this message because you are subscribed to the Google Groups "aprs.fi" group.

> To view this discussion on the web visit https://groups.google.com/d/msg/aprsfi/-/VOobU1chTBEJ.

> To post to this group, send email to apr...@googlegroups.com.

> To unsubscribe from this group, send email to aprsfi+un...@googlegroups.com.

[OK1ALX]

Hi

> Well, as I said earlier (quoted below), "I'll see what I can do to fix
> that". :)

Alright, looking forward :)

I'll write tou an email about the Prague visit.

Regards,
Libor, OK1ALX

>       > aprsfi+unsubscribe@googlegroups.com.

>       > For more options, visit this group at
>       > http://groups.google.com/group/aprsfi?hl=en.
>       >
>       >
>
>          - Hessu
>
> --
> You received this message because you are subscribed to the Google Groups "aprs.fi" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/aprsfi/-/VOobU1chTBEJ.
> To post to this group, send email to apr...@googlegroups.com.

> To unsubscribe from this group, send email to aprsfi+unsubscribe@googlegroups.com.

[Heikki Hannikainen]

Hi,

I spent a couple hours working on this.

The line should now more accurately reflect the actual path taken by the
packet.

The first line to the initial receiver (if and only if the initial
receiver can be positively identified!) will be green. The line to the
igate is purple (unless it's green), and the rest of the hops are blue.

- Hessu

[OK1ALX]

Hi
ok, it looks like it works. At least my small tests today shows that the line isn't draw to the station which didn't erlayed the packet. Good job!

It is nice to see different colours for the lines, however i must say that the green line is sometimes confusing. When station is directly heard by the igate, then you cannot easily determine by the frist look if the station was igated or not.
I would say the purple line should overide the green line if the station was heard directly by igate and was igated to APRS-IS. Or not?

Although sometimes, i don't understand the algorithm that determines the igate which will be marked as the one who igated the station :) But thats another topic.

Libor, OK1ALX

[Lynn W Deffenbaugh (Mr)]

On 5/18/2012 6:15 AM, OK1ALX wrote:
> Although sometimes, i don't understand the algorithm that determines
> the igate which will be marked as the one who igated the station :)
> But thats another topic.

Simple, the first IGate to deliver a packet to an APRS-IS server is
marked after the q-Construct. All others are dupe-detected out of
existence.

However, with a distributed system like the APRS-IS servers two Igates
could deliver a single packet simultaneously to two different APRS-IS
servers. Each of those servers would flag the packet with their
respective connected IGate. So far, so good.

But as those two packets propagate through the rest of the APRS-IS
network, one or the other will arrive "first" at each deeper server. It
is possible that different servers throughout the APRS-IS will report
different IGates for a single packet, but only one each.

aprs.fi is at the mercy of this propagation behavior of the APRS-IS.
Whichever packet his server received first is the one that will be shown
at aprs.fi. Other Internet APRS sites may have a different gate for the
same packet because their server was "closer" to one or the other IGate
along the propagation path.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

PS. Because of the dupe-suppression of the APRS-IS, APRS-IS is NOT a
suitable propagation analysis tool. No one has access to the unfiltered
RF reception feed. It's been tried before, but the protocols and
processes just don't do it.