[aprssig] Baker to Vegas Tomorrow...

Robert Bruninga bruninga at usna.edu
Tue Apr 26 23:00:06 EDT 2005

>>> steve at dimse.com 04/26/05 8:47 PM >>>

>> I need to know what was the time at the time 
>> that the FINDU processor subtracted
>> the real-time to get the AGE column....
>Geez Bob, there are only three pages like this, 
>one is B2V, which gets 24 hours of use a year,  
>and the PCSat and ISS pages..

Ah, now I am beginning to see why we are not seeing 
the same end of the elephant.  It is the PCSAT and ISS
pages that I look at every day, and the ones that I capture
as snapshots to preserve what happend on a satellite pass
or on a day of special activity.  So when I complain about
"time stamps on FINDU" pages, I am really only talking
about pages that have the AGE column.   Its when 
these pages are captured as a snapshot of activity, that the
AGE column (the most valuable data on the page) is also
meaningless without knowing the time of "now" when the
snapshot was taken.

I capture these pages and put them in Power point presentations
or lists or many other ways I analyze the data after-the-fact.
And its this after-the fact looking at the data on these pages
that drives me crazy with haivng to keep track of the instant
I hit the refresh button and somehow preserve that scribble
with the file...

>Geez Bob, there are only three pages like this, 
>[and they have the capability to]... replace the relative 
>times with the absolute UTC timestamps, which is 
>even better than what you asking for.

Well, actually it isnt.  Because what I love about the FINDU
pages *is* the processed AGE column...  But without the 
date and time of when the AGE was calculated, the files are 
frustrating void of the key to deciphering the AGE column.

Yes, you added the UTC mode, but I never use it.  Because for
most of my interest, it is the relative age, spacing and 
timing of the packets I am interested in, and this is perfectly
preserved in the AGE column.  Putting it into UTC mode
makes it a blur of meaningless numbers that have no meaning
until the start time is subtracted out.   And why would I 
ever go to that trouble, when the AGE column is what I
want all along.  (But missing the date-time stamp)...

But these are not the only pages too.  I also frequently
analyze and use as snapshots the NEAR pages, and
search by SYMBOL cgi's to give me snapshots of
activity.  And all of these have an AGE column.  I just
am asking that any page that has an AGE column
have the date and time that the age was calculated
in the header at the top of the table so that for all 
posterity, that collection of data on that page can stand 
alone and mean something.

Right now the NEAR cgi returns an EXCELLENT page
of valuable information and it even says (last 240 hours),
but it would be so much more valuable it it also said
"as of 1435z on 26 Apr 2005"

Then that page or download or refresh would be complete
and could be captured, saved, analyzed, processed,
kept, retained, and referred to and always be completely
unambiguous.  Without the time stamp, it retains no
value beyond "now"...

>Get over it

Sorry, I can't.  The lack of a time stamp to identify the
basis of the AGE column is a daily frustration to me
as I refer to these pages DAILY for commanding and
operating PCsat and for looking at the APRS NETWORK
in different areas of the country and try to ANALYZE
what is going on with the network there.  These snapshots
are very valuable for these efforts and it is just so 
frustrating that the AGE column (one of the most valuable
data sets) is useless without the page also showing
when it was calculated.

It is just so frustrating that you deny this information...
even knowing how valuable I find it to be.


More information about the aprssig mailing list