Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Take an old PC (e.g. 1.8GHz P4 with 256MB RAM), install e.g. Ubuntu 10.04 LTS on it.

Now go to your PIC or AVR based home project and hook up the thing. With only three connections and the onboard peripherals of every microcomputer, you now have a large screen and keyboard easily interfaced to the $5 gadget.

Use minicom to read/write easily to the device.

I would like to take this one step further. I need the data logged, plotted and analysed

Essentially, I imagine the product of my search as a

  1. free and open MatLab clone, adept at
  2. handling real-time data streams, with intuitive interface to
  3. graphing one or several parameters at various time spans (e.g. the temperature of 4 sensors over the last minute or week and the setpoint). Basic control theory functions would be a significant plus (e.g. max, min, overshoot, state-space model transformations, PID tuning, controller synthesis).

What tools can I use here?

share|improve this question
What type of sensors and controls are you talking about? You might not need real-time at all if your sensors are slow. – Renan Feb 19 '13 at 21:13
@ Renan, indeed, my sensors are slow. I am looking at screen refresh rates of about 1fps. By real time I mean streams as opposed to block data. – Vorac Feb 20 '13 at 11:55
up vote 5 down vote accepted

I don't know if the existing options (e.g. Scilab, or Octave with the control systems package) can deal with real-time data.

In any case, it shouldn't be hard to make your own; I would probably use Python + SciPy + NumPy + pyserial + matplotlib (+ any web framework if you eventually plan to control this over the network).

There's a control systems library for Python but I never used it too much.

share|improve this answer
The last couple of months I spent familiarizing myself with scylab, octave and python. Considering all, I consider your second paragraph a perfect answer to my question! – Vorac Aug 11 '13 at 17:32
Also, the control system library for python is quite lacking in features. Better than nothing, of course. Also, matplotlib is great for scientific work, but unusable for high refresh rate (> 1 Hz) use cases. Which is not mine. – Vorac Aug 11 '13 at 17:37
So here is a partially functional implementation of your suggestion. Maybe matplotlib will be too resource-intensive for this task, and a switch to Qt or gtkwould be made. – Vorac Dec 16 '13 at 9:24

You can use

  1. Octave for the computations
  2. either minicom with the -C option to write to a file or the termios library for the serial communication
  3. and gnuplot for the data visualisation
share|improve this answer
Your lash-up will function, but I think it will struggle to achieve "real-time" output. Here, I'd define that as 30+ frames per second update rate, so the output graph appears to change continuously. You'd probably have to pull tricks like setting gnuplot up for streaming output to X11 to have a decent chance at the 30 fps. Your only alternative to that would be to write each frame out as a PNG (or similar) and load it up into your UI, which adds file I/O and codec overhead. – Warren Young Feb 19 '13 at 19:42
@WarrenYoung He did not specify at all what real-time means for his application. I'm using the setup I described for monitoring sensor data. Since my sensors are slow, real-time means for me one gnuplot update every five seconds. Since he mentioned temperature sensors, I assume updating every few seconds is fine. – Marco Feb 19 '13 at 19:47
Real time is indeed not a well-defined term. I still think you should aim for performance at least equal to a DMM + thermistor: a decent DMM updates its display at least a few times a second. Once the system achieves thermal stability, an update every second or two is indeed sufficient, but when the temperature is changing (e.g. moving the termistor to a different place, turning on the HVAC, etc.) you want it to update rapidly so you can gauge the trend. Consider also that serial is a non-blocking I/O channel: if the gnuplot stage can't keep up, the DAQ unit will spam the PC. – Warren Young Feb 19 '13 at 20:01

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.