Telemetry auto-refresh

[Lynn W Deffenbaugh (Mr)]

If you bring up the following telemetry page:

http://aprs.fi/telemetry/a/KJ4ERJ?range=day

you should see nice-ish square waves.

However, if you let that page up through a few refreshes (data is
updated every 15 minutes, so let it up for a few hours), you'll see the
new stuff isn't square.

BUT, if you then go click the 24 hours link, the squareness is restored.

Not a problem for me, but something is definitely different between
on-the-fly graph updates and fetching a whole new graph.

Lynn (D) - KJ4ERJ

PS. I've only looked at this with Firefox 12.0 release update channel.

[Heikki Hannikainen]

On Tue, 22 May 2012, Lynn W Deffenbaugh (Mr) wrote:

> If you bring up the following telemetry page:
>
> http://aprs.fi/telemetry/a/KJ4ERJ?range=day
>
> you should see nice-ish square waves.
>
> However, if you let that page up through a few refreshes (data is updated
> every 15 minutes, so let it up for a few hours), you'll see the new stuff
> isn't square.

Ah. The telemetry & wx graph updaters are a bit dumb: they only fetch the
most recent report and add it to the graph. If there are more than 1 data
points added to the graph between two updates of the graph, only the last
one will be pushed to it.

The update interval is based on the median transmit interval of the
telemetry station. It doesn't do frequent queries to the server (to reduce
load on the server), instead it figures out when the next data point is
likely to be received and does requests around that time.

http://aprs.fi/?c=raw&call=KJ4ERJ - the transmit interval isn't quite
constant, it's jumping between 1 minute and some 15 minutes. Is that
intentional?

If this is a popular thing to do, maybe I'll have to improve the updater
to do the right thing and fetch all of the new points.

- Hessu

[Lynn W Deffenbaugh (Mr)]

On 5/23/2012 12:23 PM, Heikki Hannikainen wrote:
> On Tue, 22 May 2012, Lynn W Deffenbaugh (Mr) wrote:
>
>> If you bring up the following telemetry page:
>>
>> http://aprs.fi/telemetry/a/KJ4ERJ?range=day
>>
>> you should see nice-ish square waves.
>>
>> However, if you let that page up through a few refreshes (data is
>> updated every 15 minutes, so let it up for a few hours), you'll see
>> the new stuff isn't square.
>
> Ah. The telemetry & wx graph updaters are a bit dumb: they only fetch
> the most recent report and add it to the graph. If there are more than
> 1 data points added to the graph between two updates of the graph,
> only the last one will be pushed to it.
>
> The update interval is based on the median transmit interval of the
> telemetry station. It doesn't do frequent queries to the server (to
> reduce load on the server), instead it figures out when the next data
> point is likely to be received and does requests around that time.
>
> http://aprs.fi/?c=raw&call=KJ4ERJ - the transmit interval isn't quite
> constant, it's jumping between 1 minute and some 15 minutes. Is that
> intentional?

Yes that is intentional. I'm telemeterizing bucketized data rather than
a continuous sampling of a changing value. By repeating the last value
at the end of the 15 minutes and a new value 1 minute later I can get
the square bars that I'm after.

> If this is a popular thing to do, maybe I'll have to improve the
> updater to do the right thing and fetch all of the new points.

I'm doing it for these discrete values, and also to a lesser extent in
my KJ4ERJ-TD "The Energy Detective" telemetry. This is not from
APRSISCE/32 nor from any packet generator that I have any plans to
release. I don't know if anything else out there does it, but it works
quite nicely for the data I'm trying to capture and present.

No need to change things for this usage. I had a feeling it had to do
with fetching just the most recent value, but I didn't know that you
dynamically calculated a refresh interval. Good idea.

You could keep the best of both worlds if the refresh fetched ALL of the
datapoints since the last refresh rather than just the most recent
value. That way if a temperature or battery monitor encountered a burst
of values outside the originally calculated telemetry interval, they'd
all still show up in the accumulator-refreshed graph. Just a thought.

Lynn (D) -KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
(and other APRS-accessing programs...)




>
> - Hessu
>

[Heikki Hannikainen]

On Wed, 23 May 2012, Lynn W Deffenbaugh (Mr) wrote:

> Yes that is intentional. I'm telemeterizing bucketized data rather than a
> continuous sampling of a changing value. By repeating the last value at the
> end of the 15 minutes and a new value 1 minute later I can get the square
> bars that I'm after.

So, if I got this right, in practice, you're emulating a bar graph, with
the assumption that the receiving end cannot provide one and that the
receiving end will draw all data points with lines in between, right?

I guess that would break or become unnecessary if I did the bar graphs on
the receiving end with a user-selectable switch, or when some averaging
happens on the longer time ranges?

I would have expected telemetry stations to transmit the real, raw values
when the data is available, instead of providing dummy packets to simulate
a certain graph plotting. The presentation would be, in my mind, done in
the graphing code at the receiving end (there's a lot to improve there).

> You could keep the best of both worlds if the refresh fetched ALL of the
> datapoints since the last refresh rather than just the most recent value.

Yes, that's exactly what is on my to-do list. It also fixes the problem
when a laptop comes back from sleep and does a refresh after a longer
break.

I just did it with a single point at first, because it's always available
in memcache, and there's no need to go to the database for the history.
Have to be careful with server performance when introducing new features.

- Hessu