[time-nuts] web presentation of data

shalimr9 at gmail.com shalimr9 at gmail.com
Tue Aug 7 14:04:41 UTC 2012

Regarding plotting data files through a web page, some time ago I wrote a  
small utility to do just that. We have a corona tester here at my workplace  
that generates binary files with the corona data. These are not easily  
plotted from a standard tool because of the proprietary format.

Instead of writing a Visual something program that would have to be  
installed on all the machines that might need to display the data, I wrote  
a php app that I loaded on the local Linux server.
I also copied it to my ko4bb.com site at http://www.ko4bb.com/graph

You can try it with this file (which you need to download to your local  
hard drive first, so that you can upload it to the tool :)


This software could be easily modified to print any standard file format  
(comma delimited or else) and to adjust the width/height of the picture to  
your liking. Save the picture size in a cookie so that you do not need to  
enter it each time and you are done :)

The source code is there:


Didier KO4BB

On , John Ackermann N8UR <jra at febo.com> wrote:
> I think there are now a couple of threads going on about this topic,  
> which I started by a clumsy attempt to use the "WIDTH" and "HEIGHT"  
> attributes in HTML. :-)

> For what it's worth, I usually scale web graphics to no larger than 750  
> pixels horizontal or 550 pixels vertical. That goes back to the days of  
> lower resolution monitors, but still works well with the page layout I  
> use at febo.com.

> The challenge in this case was that using the default settings in John's  
> TimeLab program, I'm getting plots that are about 1350 pixels wide and  
> (as PNGs) are ~130kB in size. When down-sampled, it can become difficult  
> to read the fine data. The best way to handle that, I think, is to create  
> a scaled version of the image and use that as a link to the full-size  
> version. Something like:

> But that's extra work that I haven't gotten around to automating yet, so  
> I thought I'd try using the HTML size options:

> The viewer can then right-click on the image and via the "view image" or  
> similar menu open up the full-sized version for the fine detail. That  
> worked on my browser and monitor, but apparently not on some other  
> combinations. So, it's back to the drawing board.

> Moving to the second thread on plot generation generally, apart from  
> TimeLab I do most of my data capture and analysis in Linux. I typically  
> break the two into separate pieces:

> 1. A single-purpose program (usually written in Perl because I make  
> slightly fewer errors with it than other languages) that talks via GPIB  
> or serial port and outputs a data file with typically MJD and phase or  
> frequency information.

> 2. A graphing tool that reads the data file. For this, I'm quite fond of  
> a program called "Grace" (http://plasma-gate.weizmann.ac.il/Grace/) that  
> provides a WYSIWIG graphics interface and saves plot information in an  
> ASCII format that's pretty easy to muck around with. Grace is packaged  
> with Debian-based Linux distributions; I don't know if there's a Windows  
> version available.

> I've also done some automatic plot generation to go from data file to  
> regularly updated web page. This involves some fairly ugly text  
> processing taking advantage of Grace's batch mode, but the result is a  
> tool that will read the data file, do whatever statistics are desired,  
> combine with the Grace command file, run Grace in batch mode, and create  
> an output PNG file that's uploaded to the web. It's actually fairly easy  
> to do once you figure out the appropriate black magic...

> John

> ----

> On 8/6/2012 11:34 AM, Jim Lux wrote:

> what would be useful is to have some sort of "plotting engine" that is a

> canned webpage (or stored locally on the user/client computer) that can

> ingest fairly raw data from a URL..

> something, conceptually, like this:

> *invocation of plotting engine*

> data value 1

> data value 2

> data value 3

> that way, a relatively dumb controller (think arduino-ish) could talk to

> the instrument and build a web page on the fly without having to do much

> formatting. The java/javascript/whathaveyou would do all the plotting

> work on the client side (where, presumably, they have a display and some

> computational horsepower to drive it)

> A low end microcontroller has no problem serving readonly pages from

> flash/SD, it just has a tough time doing graphics.

> And, if you wanted the raw data, you serve up a page called "raw.html"

> or something that just has the raw data.

> _______________________________________________

> time-nuts mailing list -- time-nuts at febo.com

> To unsubscribe, go to

> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts

> and follow the instructions there.

> _______________________________________________

> time-nuts mailing list -- time-nuts at febo.com

> To unsubscribe, go to  
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts

> and follow the instructions there.

More information about the Time-nuts_lists.febo.com mailing list