[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnucap-devel] A potential waveform viewer

From: Arnaud Gardelein
Subject: [Gnucap-devel] A potential waveform viewer
Date: Sun, 04 Jan 2009 01:50:53 +0100

A few months ago, looking for free software electrical simulator, I gave
a try to gnucap. And finally started to use it for my personal projects.
I also searched for a waveform viewer, found gwave and gwave2. I tried
to use gwave2 but got lots of dependencies-related problems (mainly
guile-gnome-platform). So I switched to octave.
In the meanwhile, there was a thread about waveform viewers in this
list, around the March 18, 2007 where Dan and Al gave some specs for a
such a tool.

Well, I am not really skilled in Python, but I tried to write a KISS
program able to view results of Gnucap, following the guidelines thrown
by Dan and Al. Since Gnucap is designed as if you would put probes on
your board, I called it oscopy, a kind of oscilloscope in Python. There
is a dependency with matplotlib/pylab. It is hosted here:
There is a screenshot here:;f=oscopy.png;h=41e88db954208349ef9e9fab8714b8b734ae4c8d;hb=HEAD
The principle : load the signals from datafiles, prepare figures and
graphs by creating figures, adding graph and inserting signals, set the
display mode (log-, FFT-, ...), the layout (quad, vert, ...) and view
the results (plot).

My first idea was to use Python to load datafiles and octave to view
them, but finally matplotlib is more convenient. The only thing is that
you have to close the all the graphical windows to continue.
I implemented it as a commandline program, but the adaptation to a GUI
should not be difficult, using pygtk for example.
Basic math are supported through the math module from python, FFT is
also present. It should be easily extensible by deriving classes
implementing file reading (Reader) and data plotting (Graph).
I set the maximum number of graphs per figure to 4, because on my
machine results are unreadable for more graphs. However there is no
limit to the number of signals that can be inserted into a graph.

It is far from perfect: memory inefficient, not optimised, certainly
full of nasty bugs, poorly tested, and suffers from my quite recent
knowledge of Python. So please be indulgent if ever you test it.
Comments, suggestions, patchs, bug reports are welcomed !

I hope this would help.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]