iGATE statistics- packets heard counters?
Mike, OE3MZC
I have observed severe differences while loooking at the info page and graphs of i-gates at aprs.fi .
Some show very high numbers of packest received and gated to internet or packets heard first..
while others show only numbers like 1 to 4 packets. This even happens in same geographical area and with comparable setup.
See OE1PDB-10 and compare to OE3YCB-4.
Question: is it received packets per HOUR? (I guess but at least in German it is not specified in graph)
Question: what is the algorithm for these counters?
However, when I observe the upload of OE3YCB-4 to the tier2-APRS-IS network this i-gate does send/upload much more received packets to the IS-Aprs server
than what is indicated at aprs.fi statistics!?
Is it a question of internet speed of connection?
Your help appreciated. tnx.
Happy New Year!
de Mike, OE3MZC
Heikki Hannikainen
> while others show only numbers like 1 to 4 packets. This even happens in
> same geographical area and with comparable setup.
> See OE1PDB-10 and compare to OE3YCB-4.
> Question: is it received packets per HOUR? (I guess but at least in
> German it is not specified in graph)
It's packets per hour (the graph bars have width of 1 hour and there are 6
of them between the 6 hour timestamps). I thought it might be obvious but
maybe a label would be in place!
> Question: what is the algorithm for these counters?
> However, when I observe the upload of OE3YCB-4 to the tier2-APRS-IS
> network this i-gate does send/upload much more received packets to the
> IS-Aprs server
> than what is indicated at aprs.fi statistics!?
> Is it a question of internet speed of connection?
They actually count the amount of packets received by aprs.fi after a lot
of duplicate packet filtering has happened in the APRS-IS. If two igates
hear the same packet, they will traverse through the TIER2 APRS-IS servers
to aprs.fi, and depending on the path they happen to take, only one will
survive (the quickest one). It's a function of the latency (in
milliseconds) of your Internet connection, and the latency between the
IS servers. Not the bandwidth "speed" (bits transferred per second).
I guess the labels should be adjusted to indicate that. And the manual:
http://wiki.ham.fi/Aprs.fi_Info_pages#Info_graphs
- Hessu
Mike, OE3MZC
tnx clarification. I have tried serveral TIER2 APRS-IS servers.
but what is the difference between:
and
I ask this question because I have encountered problem with packets received by my wifes Igate (OE3YCB-4) not getting through in time or not beeing listed in raw data.
Situation:
I send some poits with my VX-8 handheld. I observe it beeing received and gated to ISserver sucessfully, I observe same packet beeing digipeated around my area several times.
I then check for this packet in the raw data of aprs.fi and dont find it listed. However packets that have been digipeated are listed correctly.
I do not understand this, so I made some futher test tonight during night time:
I setup my son's handheld (HB9EUT-7) to transmit POSITS evry 30sec, but with very low power so that only our Igate (OE3YCB-4) could hear it and no digipeater (nobody else)..and let it run for some hours...
Result:
statistics of OE3YCB-4 Igate at aprs.fi show:
approx 120-130 packets received and packets passed from RF to APRS-IS ....which seems ok!
but it also shows in diagram below:
ONLY approx 30x RF packets heard first ... which seems to be wrong by definition!? (because for sure nobody else could hear the weak local signal of my son's HT)
Any clue on this? and how can I use these data to check if my Igate is working correctly?
mni tnx in advance.
Lynn W Deffenbaugh (Mr)
What mode is the software using to interface with the TNC? (KISS, Host, SoundCard?)
Does it have RF-received logs that you can access?
This question is probably better addressed to the support group of your IGate software and has nothing directly to do with aprs.fi.
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
--
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/-/2pXd7632hwQJ.
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
> but what is the difference between:
> iGate'd packets by OE3YCB-4: 2012-01-12 13:00:00 -> 2012-01-14 13:27:23 UTC
> packets passed from RF to APRS-IS
Packets which were igated by that station *and* made it through APRS-IS to
aprs.fi.
> and
> RF packets heard first by OE3YCB-4: 2012-01-12 13:00:00 -> 2012-01-14 13:27:23 UTC
> RF packets heard first (bogus, unreliable)
Those packets which were most probably heard first by OE3YCB-4 (igate or
digi), and which made it through APRS-IS to aprs.fi.
> I ask this question because I have encountered problem with packets received by my
> wifes Igate (OE3YCB-4) not getting through in time or not beeing listed in raw data.
If packets are
1) being received by that igate (you can see it in it's log file or
screen)
*AND*
2) not being received by any other igate (low enough power), so that the
packets in queastion are not displayed on aprs.fi
it is a problem in your igate configuration or the server you're
connecting to. It's not a problem with aprs.fi. Please get in touch with
your igate software's support group.
> ONLY approx 30x RF packets heard first ... which seems to be wrong by definition!?
> (because for sure nobody else could hear the weak local signal of my son's HT)
Maybe you're transmitting with an APRS path which could indicate that the
packet might have been digipeated already, such as WIDE2-1 (quite probably
a WIDE2-2 which has been digipeated once).
- Hessu
Mike, OE3MZC
>>What IGate software and hardware (radio and TNC) are you running?
this setup worked fine for many years now!
>>What mode is the software using to interface with the TNC? (KISS, Host, SoundCard?)
>>Does it have RF-received logs that you can access?
but not showing up on apsr.fi/raw/
in aprs.fi/raw/ listing you will see some digipeated version of same packet listed...which is much later in time.
>>This question is probably better addressed to the support group of your IGate software and has nothing directly to do with aprs.fi.
tnx 73 de Mike
Mike, OE3MZC
thank you for all clarification.
I just tryed to use these statistics for tracing down my presumed problem with my Igate.
After performing some more tests something remains still unclear to me:
path is ok and does not lead to false assumptions regarding "first heard"
[HB9EUT-7>TX1Q00 via WIDE1-1,WIDE2-2,qAR,OE3YCB-4]
if I now use my VX8 to send beacons that are only received by my Igate OE3YCB-4 (nobody else hears them)
and I tx each 30 sec
then I see in statistics 120 packets gated to Inet
but only 30 are presumed "first heard" according to graph.
ok, you have stated " unreliable" ..acceted and ok.
But then I do different setup:
produce beacons that are heard by other APRS Digis on QRG,
so my Igate should hear first and Igate to tier2 (which it does according to logfiles)
and after some SECONDS (much later in terms of network latency!!) some other Igates will pick up the digipeated version of same postion.
however, if you now look into the raw tables of aprs.fi there is only the digipeated packet listed, but not the first original one, which has been igated by oe3ycb-4
and I have changed Internet provider, aprs2-server etc... no success so far.
So this seems to be not just statistics?
I am not saying this is your (aprs.fi) fault. I just wanted to use the graphs and raw data to pin down the reason for this problem.
tnx
73 de Mike
oe3mzc
Heikki Hannikainen
> I just tryed to use these statistics for tracing down my presumed problem with my Igate.
I don't think there's anything wrong with your igate.
> if I now use my VX8 to send beacons that are only received by my Igate OE3YCB-4 (nobody else
> hears them)
> and I tx each 30 sec
> then I see in statistics 120 packets gated to Inet
> but only 30 are presumed "first heard" according to graph.
> ok, you have stated " unreliable" ..acceted and ok.
Just checked the code - if a station hears another single station more
than once within 1-2 minutes, the "heard" statistics are not updated for
more than the first packet.
So if you transmit too often (30 seconds from a static position seems
abusive), it will optimize away the updating of the "heard" database
tables.
To make this a bit more confusing, it seems like the "igated" statistics
are updated before this rate limiter is applied.
2 minutes is quite a long time, I guess it will reduce the filling of
http://aprs.fi/heard/ maps a bit too much since as a station could
traverse through a couple of blocks during that time (they're only 2 km
wide here). Maybe that filter should be reduced to something like 30
seconds. The igated and heard graphs would get closer to each other due to
that.
That rate filter is an old one, it's older than the /heard/ heat map and
the statistic graphs in question. It made more sense when there were only
the "heard" tables shown on the /info/ page. I'll have to test the
performance impact of tuning the timer.
> But then I do different setup:
> produce beacons that are heard by other APRS Digis on QRG,
> so my Igate should hear first and Igate to tier2 (which it does according to logfiles)
> and after some SECONDS (much later in terms of network latency!!) some other Igates will pick up
> the digipeated version of same postion.
> however, if you now look into the raw tables of aprs.fi there is only the digipeated packet
> listed, but not the first original one, which has been igated by oe3ycb-4
> and I have changed Internet provider, aprs2-server etc... no success so far.
By "raw tables", do you mean the "raw packets" display at
http://aprs.fi/?c=raw ?
This is more odd, and a different issue from the previous one (and more
likely has nothing to do with aprs.fi - aprs.fi has no idea of your
transmit power or antenna!). Sounds like the packet is not getting from
your igate to aprs.fi for one reason or another. But I can't understand
why your igate would stop working when you increase power.
There could be surprising explanations, such as higher transmit power
tripping up your Internet connection (RF interference on phone line),
causing packet loss and slowing down your igated packet on the link to the
TIER2 server enough that it gets eaten by the APRS-IS duplicate filter. Or
something like that. Just a guess. You could run 'ping' continuously to an
outside server to verify that the line is stable while transmitting.
Can you please point to an example of this happening, URL, exact date and
time so that I can look at the logs myself?
- Hessu