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 <j...@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@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@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
