1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
|
x*oscope infinite TODO list, in rough order of suggestion
This is a the original text of (most) everything that's been
thought up or suggested along with my comments and any status
updates. Things that are mostly done have now been moved to
TODO.old for historical reference. I don't know how many of
the remaining ones will ever get done or if some of them are
even practical without major work.
1 16 bit sampling (Jeff_Tranter@Mitel.Com)
Oscope would just divide by 256 to show 1/1 scale. The
obvious advantage to this is better clarity when you zoom in
on signals of small amplitude, or for use with x10 probes.
For math to work, the size of everything would need doubled
from 16 to 32 bits to avoid overflow.
v1.1: I made a hardware solution for amplifying x10 probes. See
HARDWARE and buff.*. 16-bit would still be useful though.
v1.10: COMEDI data source handles 16-bit devices, though math may
still need to be fixed to avoid overflow
3 envelope mode (Jeff_Tranter@Mitel.Com)
This only applies at slower sweep speeds, right? See #23.
4 make drawing area mouse aware (Jeff_Tranter@Mitel.Com)
Be able to drag signals up and down for example.
v1.6: Under GTK+, left-click will select a channel and right-click
is a context-sensitive pop-up menu.
v2.0: This is broken
7 smarter maximum sample rate (twitham@pcocd2.intel.com)
If your sound card can do greater than 44kHz, oscope won't
currently take advantage of it. It should determine the
optimum rate at run-time. I used 44kHz because it was the
most my card could do at a one sample per pixel screen
resolution. But, for example, if your card can do 88kHz it
could plot every other sample until you zoom in to get 1:1.
8 trigger on math or memory (twitham@pcocd2.intel.com)
You could hide 1 and 2 and use an external command as input.
Also allows you to trigger when 1 equals 2 or whatever.
Problem - how to handle things like the Bitscope that
_have_ to have a trigger. See #33.
9 show pre-trigger samples (twitham@pcocd2.intel.com)
Let user position trigger horizontally. Remember samples
until we find trigger, then capture h_points - pos more.
v1.4: Of course this wouldn't work with ProbeScope since we have no
samples before trigger.
10 external command history (twitham@pcocd2.intel.com)
Remember previous commands and make them available in a list.
Possibly record them all to the data file.
v1.6: GTK+ interface now has a combo box of useful commands.
11 vertical scale calibration (Grant_Siemers@ccm.fm.intel.com)
Ask user to apply a signal of known amplitude and use the
result to correctly label voltage on the Y axis. I wonder how
many folks could actually do this?
v1.4: ProbeScope voltage is labeled correctly, no calibration needed.
v1.10: COMEDI voltage is labeled correctly, no calibration needed.
12 channel colors (Grant_Siemers@ccm.fm.intel.com)
Let user customize the colors of the channels.
15 autosetup (Sean_Eilert@ccm.fm.intel.com)
Auto-find one period and set the time scale appropriately.
23 more acquisition modes (twitham@pcocd2.intel.com)
With #22, we could do various modes like peak detect,
envelope, average. I'm thinking all samples could really be
stored in memory in which case these would really be display
modes. That is, how you see a combination of samples
represented at one horizontal pixel position on the screen.
25 separate sample / display buffers (twitham@pcocd2.intel.com)
Internally, collect samples in a different buffer and then
move them into a separate waveform buffer. This would greatly
simplify implementation of several of the above features.
v1.3: I've re-written the display routine to understand arbitrary
sample rates. Well, anything below 44000 for now. So maybe this
won't be necessary.
v1.4: The display now works with rates up to 20,000,000 S/s.
v1.8: The display now works with rates up to at least 25,000,000 S/s.
32 Improved display handling
Right now, the graticule (display grid) is re-drawn every time
the data changes. Under X Windows, the display code could be
implemented using a bitmask to prevent the signal lines from
drawing over the graticule when it is in "over" mode. In
"under" mode, the inverse bitmask could be used to "draw"
the signal lines only where the graticule is, using the
color of the graticule. End result should be more efficient
X Windows performance.
On a psuedo-color (or svgalib) display, signal lines could
be drawn using reserved bits in a custom colormap,
removing the need for any special graticule handling at all.
Code could be smarter about figuring out which x-coordinates
have been erased, and only re-draw signal lines for those
coordinates, instead of redrawing entire signal lines.
Don't have to use backing pixmap unless we're in accumulate mode.
33 Multi-threading
Some of the data sources (like Bitscope) tend to block and wait
for serial line operations. An easy way to avoid this would be
to implement a multi-threaded data source interface, where the
data collection thread ran independant from the display thread.
Main problem I see here is synchronization between the main
thread and the data collection thread, especially at the end
of a sweep - you have to signal the main thread that data
is ready, then wait until everything in the main thread is
done processing the data before starting a second sweep.
34 16-bit and digital triggering
Triggering code currently works well for 8-bit triggering
(the original soundcard design), but for 16-bit sources
and digital sources, not so well. How to scale the trigger
values for 16-bit sources, and do something intellegent
with digital triggering sources?
38 X-Y mode
39 Fix problems relating to signalline/display code
What to do with history when settings like analog/digital are changed?
We want the changes to be 'undo'able, but it doesn't really make
sense to keep the history around - does it?
Figuring out cursor data values
99 mini TODOs
new defaults - default device, default min update interval
memory utilization
figure out how to use stock buttons on Glade dialogs
count.dat
anti-jitter in COMEDI's rt_timer
max rate option in COMEDI's rt_timer
fix multi-sample scan delay in COMEDI's rt_timer
investigate RTAI scheduling issues - how badly do we need anti-jitter?
ability to resize to a small(er) window
COMEDI gain control
time scale normalization - when it's done and how
noise causing false triggers on 16-bit data sources
should we note clipping? older versions did
COMEDI rate logic
make sure -m option works (screen size)
cursors - should always show same voltage left/right
cursors - move around if sampling rate on active channel changes
fix GTK widgets so they don't keep "wiggling around"
allow user to specify an rc file
maintain scrollbar position on timebase change
save entire display state on a file save
import/export signals in standard formats
better job of handling slow timebases
improve FFT code
fix value-to-pixel roundoff problems in gtkdatabox
COMEDI range control
ALSA number of channels; rate logic
handle wide text boxes on long external commands
better handle external commands with variable time bases
don't open/close soundcard so much
|
