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