[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 :)
http://www.ko4bb.com/graph/006.DAT
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:
http://www.ko4bb.com/graph/index.php.txt
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