web presentation of data
On Tue, Aug 7, 2012 at 6:45 AM, Jim Lux jimlux@earthlink.net wrote:
On 8/6/12 10:43 AM, Chris Albertson wrote:
On Mon, Aug 6, 2012 at 8:34 AM, Jim Lux jimlux@earthlink.net 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:
<BODY> *invocation of plotting engine*data value 1
data value 2
data value 3
What you are saying is that the data needs to be rendered to a graphic
locally. I think the simplest way is to create vector based plots on the
server (I've used GNU Plot inside a CGI script) but there is a system to
pretty much what you are asking for. http://code.google.com/p/flot/
Somehow, I don't think running Gnuplot on a Arduino is feasible. ABout
all it can do is respond to the HTTP "Get" with the right page.
That's why I want to push the hard work of doing the rendering onto the
client (i.e. the browser). The comm link is fast, and an SD card on the
Arduino can hold tons of stuff, so serving a page containing 100kbytes of
Java or similar isn't a problem. But doing any computation is probably not
in the picture.
So the web server is inside an Arduino? Yes can't run GNUplot there. Why
not have the Arduino produce either Postscript or PDF? It is very easy to
draw a graph in Postscript. Postscript is just ASCII text that contains
statements like "Draw a line from (2.34,6.65) to (3.45,78.4)" You can draw
using your application's natural units, then you apply a transform to map
those to output units like inches or cm. Later the web browser or the
printer turns those draw commands into a rasterised image fro display.
Postscript is very compact. A few KB would be more than enough for a
graph. The advantage is that the output resolution is "perfect" because
your lines are drawn using natural units with as many places after the
decimal point as you like. So your users can zoom in if they want to
1000X zoom and see details, not pixels. It wil fet on any screen
Also everyone already has the display engine. PDF is very much like
Postscript. but I think Postscrip in "EPS" form is easy to create inside an
Arduino,
--
Chris Albertson
Redondo Beach, California
Le 07/08/2012 17:56, Chris Albertson a écrit :
On Tue, Aug 7, 2012 at 6:45 AM, Jim Lux jimlux@earthlink.net wrote:
On 8/6/12 10:43 AM, Chris Albertson wrote:
On Mon, Aug 6, 2012 at 8:34 AM, Jim Lux jimlux@earthlink.net 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..
<snipped>
So the web server is inside an Arduino? Yes can't run GNUplot there. Why
not have the Arduino produce either Postscript or PDF? It is very easy to
draw a graph in Postscript.
<snipped>
Also everyone already has the display engine. PDF is very much like
Postscript. but I think Postscrip in "EPS" form is easy to create inside an
Arduino,
One good reason for doing as little as possible in a micro-controller is
that they are often used to collect raw data with as little latency as
possible. Doing web serving on a single slowish core in that case is not
a good idea. I have a bunch of Soekris doing data collection and if I
start to do compute intensive tasks on one, it skews the timing, so I
use a completely independent one to do the web serving, with the data
collectors providing access to data via nfs which does not seen to
impact the timing much even though I can't guarantee that requests are
satisfied in otherwise idle time . I like the idea of client side
graphing. It probably exists already somewhere though I haven't checked
details - RGraph pops up with google.
--
Les chiens aboient, et la caravane passe.
One good reason for doing as little as possible in a micro-controller is
that they are often used to collect raw data with as little latency as
possible. Doing web serving on a single slowish core in that case is not a
good idea. I have a bunch of Soekris doing data collection and if I start
to do compute intensive tasks on one, it skews the timing, so I use a
completely independent one to do the web serving, with the data collectors
providing access to data via nfs which does not seen to impact the timing
much even though I can't guarantee that requests are satisfied in otherwise
idle time . I like the idea of client side graphing. It probably exists
already somewhere though I haven't checked details - RGraph pops up with
google.
You are right about i being easier to not mix real-time and backround tasks
on a small uP. But it can be done. The way to do it is to make the
real-time task interrup driven. You can use a timer that goes off (say) 50
ties per second and in the handler you do your real-tie data collection or
poll the hardware, read sensors or whatever. Then in the background task
you run the web server. This way there is never a chance of something
like network requests slowing down the data collection.. A simple two
task "multi-tasker" is easy. It gets harder when you have more tasks and
I'd fgo with some kind of OS even it that required a larger uP.
That said. Even if it is easy I'dstill put the web server on a "real"
computer and only pass data out of the arduino. But it could be done. I
build a web server (and an FTP server) into a CCD camera and there is no
performance issue at all. Even during an exposure while reading out the
CCD chip.
As for going the graphics in the client. That really is easy now that
every client computer has a PDF viewer. Simply make your graph a PDF
document.
Chris Albertson
Redondo Beach, California