Clearly commercial oscilloscopes are over priced; the main goal of this project was that the cost of the PC based oscilloscope should be as low as practically possible, the total cost was expected to be less than £50 and this figure was used as guild when selecting hardware components. Clearly this goal has been achieved as the total cost of PCB components was calculated to be £22.97 (retail price), obviously this does not include the cost of the PCB board (about £7), case (about £5) and manufacturing costs (about £15), but the total product costs should be under £50.

Note the software application should be freeware, including full source code; hence customers can modify code making improvements and adding additional features, these customers could be encouraged to send their customised copy of the program to the author so that some of these changes could be included in new releases of the program.

Clearly this project is cheaper than any other similar product on the market as the nearest was a 20 kHz single channel PC based storage oscilloscope (-5 to 5V) at £95.  It is also clear that this project has many technical advantages over existing products, for example it is a quad channel oscilloscope and commercial quad channel oscilloscopes are extremely expensive (including commercial PC based scopes). It is foreseen that the oscilloscope could be available in kit form, were customers would buy the PCB components, PCB board, case, leads and build the scope themselves; this is a real option as the hardware circuitry is extremely simple and this would reduce product costs making the product more economical.

Core objective “design and construct the hardware required for data acquisition”, clearly this objective has been successfully achieved. The PIC16F877 is use, this microcontroller is extremely powerful running at a 20MHz, it has a built in 10-bit ADC which can be connected to anyone of 8 input pins, and a hardware UART suitable for RS232 communications.

Evidently the analogue circuit was proven to work, as it was simulated in electronic workbench and then in the laboratory using real components. Obviously the analogue circuit needs to be redesigned so that the PIC microcontroller can control the input voltage range, as stated in this report, there are a couple of different ways of achieving this. The first, analogue switches could be used to switch in different resistor values to the op-amps, hence changing the gain (e.g. MAX4066 or MM74HC4066). The second, and more likely option is the use of digital potentiometers (resistance controlled by microcontroller), to change the gain of the op-amps.

The circuit has built-in protection (diodes), to make sure the ADC does not get damaged by high or negative voltages, but there is no protection at the inputs to the op-amps. Clearly this is a problem, what happens if the wrong range is selected and 200V is fed into the -2.5V to 2.5V range, this will destroy the op-amps; allow the diodes at the PIC ADC pin should protect the PIC, hence it is inexpensive to fix. It is also important to note that resistors normally have a maximum voltage rating of about 200V, hence for safety reasons it is better for the 100kΩ resistor for the -250V to 250V input range to be made up of several resistors in series (i.e. 3 x 33kΩ, 1 x 1kΩ).

The RS232 transport medium was chosen, the main reasons why it was chosen is because it is easy to program, reliable and every PC has at least one RS232 port. The main disadvantage of RS232 is that it is slow (115Kbps max and will limited the maximum real-time sample rate) when compared to other mediums (e.g. USB 12Mbps). The USB port is ideal for this type of application, but because a USB port can have many devices daisy chained, the communication protocol must be complaint with the USB standard. This USB communication protocol standard is quite large and complex, and it was decided that it would take too much time to implement. Note the scope program is designed to flexible, hence sometime in the future the transport medium could be changed allowing for faster real-time sample rates.

Included in this report were design details of the real-time communication protocol, this included the frame structure and some maximum sample rate calculations at different baud rates. There are two real-time sampling modes, the first is chop mode where channel 1 is sampled then channel 2 then channel 3 then channel 4. Clearly this causes a number of problems, the first is that RS232 throughput must be shared between all channels hence this reduces the maximum sampling rate, the second is that because it takes time for the ADCs sampling capacitor to charge (20µs), there is a time delay between sampling each channel (e.g. channel 1 will lead channel 2 by 20µs). Obviously this waveform offset can be software corrected, for example a future version of the scope program could have a ‘calibration’ dialog which allows the user to software offset channel timings to compensate for this 20µs delay between waveforms. 

The second real-time mode is ‘alternate’ basically this samples channel 1 1000 times, then channel 2 1000 times, then channel 3 1000 times, then channel 4 1000 times. Clearly this has the advantage of maximising the real-time sample rate (channels don’t share RS232 throughput) no matter how many channels are enabled, but continuous monitoring of a waveform is impossible as there are gap in the data and channel phases are lost (e.g. CH1 leads CH2 by 90^o). Allow since the PIC knows how must time has elapsed (PIC timer) since sampling the pervious channel, this information could be transmitted to the PC, where the scope program could software correct the phase of each waveform. Obviously this mode is only useful for periodical waveforms (e.g. sinewaves) and not for example an ECG signal.

Evidently the maximum real-time sample rate is 5.75 kHz, which is the maximum throughput of the real-time frame structure through RS232 at the maximum baud rate (115kbaud). Clearly there is no reason why more than one serial link could not be used to increase this real-time sample rate, for example two bytes are sent per ADC reading, hence COM1 could be used to transmit the first byte and COM2 could be used to transmit the second byte (11.5 kHz sample rate). Obviously the chosen PIC has only one hardware UART, hence a software UART is required for the second com port (easy to achieve using CCS compiler) but this will push the PIC to the limits but should be ok at 20MHz. No extra hardware (i.e. no extra cost), except for another serial cable is required as the MAX232 is a dual line driver chip hence there is a spare set of drivers that can be used for this additional com port. Undoubtedly if the PIC struggles to cope with the additional software UART, a separate hardware UART could be used.

Since the RS232 communications is the bottleneck when operating in the real-time mode, it is important that the real-time frame structure is as efficient as possible. Unmistakably that’s the reason why the real-time structure does not have a check sum or CRC. Clearly, this causes a problem, however the frame structure is designed in such as a way that some errors can be detected, but the cable between the MAX232 buffer and the PC will be high quality shielded cable (short length) and errors should not occur that frequently anyway. If one or two readings are lost/corrupted, it is clear the appearance of the waveform will not be affect too much, as there are at least 10 readings per cycle and because it is real-time the screen is continuously refreshed, hence the error will probably not stay on the screen for very long until it is replaced by new readings.

Clearly a Windows based C++ application capable of displaying low-frequency waveforms from four channels simultaneously in real-time has been successfully designed, implemented and proven. The scope program graphically displays waveforms without flicker, it has a good user interface that is easy to use, and directly communicates with the PIC. There were many problems during development, some of which have been described in detail in this report (e.g. Windows 95/98/ME compliably problem). These problems are all part of the learning curve, for example one of the early problems was drawing the traces without flicker, and this problem was solved by drawing the trace to a memory DC (bitmap) and then quickly coping this to the screen. Before hand it was not known how to achieve this, hence new knowledge has been acquired. Clearly the graphical display works well and is extremely flexible (e.g. auto resizable, user adjustable grid resolution and colour).

The graphical display is designed to display the waveforms as it would appear on a traditional oscilloscope. The standard resolution (allow this can be modified up to 99 by 99) is 10 by 8 squares (that’s 100 by 80 dots), and has a user configurable trigger (software trigger). This triggering operation took some time to implement, there were many problems at first, but eventually most of the problems were ironed out, a view still remain e.g. unstable CH2 trace when triggering off CH1 if waveforms are unrelated. The user can select from a range of different triggering methods (e.g. low to high, high to low, level or edged etc…) and which channel they which to trigger on (e.g. 1,2,3, 4), including impendent triggering where each channel is trigger independently of each other, this feature is not possible on traditional analogue oscilloscopes, it is not sure how useful this feature is, buts its another one of those features (‘Bells and Whistles’) that gives this project an edge over existing similar products. Notice the split screen feature; were the graphical display is on the left hand side and the controls are on the right, just as they would appear on a traditional oscilloscope.

It is clear that the scope program can display multiple scope windows, each one with its own selected channels enabled, impendent triggering, time-bases, scales and grid resolution. It was not sure how useful this feature might be and during development it was considered that this feature may have been dropped on the finished application. Fortunately this was not the case and indisputably it may have some use for specialist applications and it’s another one of those features (‘Bells and Whistles’) that sets this project apart from other similar products. It is clear that there is no limit on how many scope windows can be opened simultaneously, perhaps until the computer runs out of memory, which on a modern PC could be 1000s of windows.

Evidently direct access to the hardware is not allowed under Windows NT/2000/XP. Hence the reason why interaction with the serial port was achieved using a file handle and various WIN32 communication API’s. Note this method is also Windows 95/98/ME compatible.

The scope program has been successfully tested on Windows 98/NT/2000/XP and theirs no reason why the program should not work on Windows 95/ME, allow comprehensive testing is required. Simulated random noise tests running for hour’s non-stop, was used to test the reliability of the scope application, (e.g. can it recover when the noise is removed or has it crashed) the program continued to operate correctly once the noise was removed, but when the noise was present (no CRC check in real-time mode) all sorts of strange waveforms were being drawn on the display.

Clearly there is problem when the user has selected an out of range time-base (i.e. aliasing can occur, even if sampling at more than twice the waveform frequency), recall that the scope program increases the time-base by skipping readings and decreases the time-base by duplicating readings. Obviously it is possible for aliasing to occur (skipping reading) if the selected time-base requires for less than 2 samples per cycle to be displayed, hence it is important that the user makes sure that the selected time-base is optimal for the waveform being monitored at the selected sample rate.

Evidently the scope program is far too processor hungry and future modification is required to make it more efficient, for example the trigger point for all enabled channels are always calculated even if all channels are triggering of one channel, clearly this is inefficient and bad programming practice and needs to be improved.  It has been proven that the scope program requires a reasonably fast PC to run smoothly, the minimum spec being 200MHz (for a reasonable refresh rate) and probably 500MHz for quad channel operation at a high refresh rate (50ms) and resolution. Clearly modern PCs will have no problems running the scope program as the minimum spec computer on the market today are all above 1GHz with the top-range above 2GHz, and computers up to 3 years (300 MHz or above) old should conformable run the scope program.

Obviously the development of the scope program is not complete and there remains many additional features yet to be added, for example the addition of 4 user configurable virtual channels (e.g. VC1 = CH1 + CH2, or CH1 – CH2, or CH1 * CH2, etc…), auto frequency calculation, auto time-base, auto voltage scale, print directly from scope program and storage mode operation. Overall good progress was made, the program can display up to four real-time waveforms either scrolling across the screen or triggering, waveforms can be saved and reopen, graphical display can be exported to a bitmap or the Windows clipboard, voltage scales are adjustable, zero point and waveform offset easy adjustable using unique user interface (small triangles) and channels are easy disable/enabled.

The philosophy used during the development of the PIC embedded software was to keep it simple, straightforward, comprehensible, and to a minimum. Many small programs were designed for testing the hardware and ideas; clearly the end result is that the PIC code was gradually built up step-by-step, instead of writing the entire program at once. Evidently this ensures that operational results are obtained, as testing producers were carried at each stage, while if the program had been written all at once, there would have been little chance of it working and could have proved difficult to debug. The high-level programming language C was chosen and not the low-level assembly code normally associated with PIC programming, clearly there are many advantages of this including: ease of programming, ease of modification, reusability of code, and use of standard functions. Clearly PIC embedded software (mark9.c) was successfully designed, implemented and tested to read the ADC at a certain sample rate (interrupt time-base) and transfer the data to the PC using the real-time communication protocol.

It is clear that a Windows dialog based simulator program was successfully developed, this program is easy to use: the user selects the type of waveform, amplitude and frequency for each channel. The simulated waveforms are then transmitted to the scope program using the real-time frame structure (storage not implemented). Clearly accurate timing is difficult to achieve, and no attempt has been made to achieve this as it would have wasted a large amount of time, plus the timing of the simulator would have been completely different to the timing of the PIC hence the code would not be reusable (actuate timing on PIC only), Clearly even though the simulator does not have actuate timing it still is a powerful tool, it will allow the communication protocol, graphical display and triggering method of the scope program to be easily tested before the hardware is constructed and PIC embedded software is written. This program works well and was successfully used to test the scope program, allow storage mode operation and the control protocol are yet to be implemented; hence more development is still required.

Evidently the entire system has been demonstrated to work together as a basic real-time low-frequency oscilloscope (up to 5 kHz) as the test results show in chapter 11. Clearly the maximum possible real-time sample rate is 5.75 kHz (with one RS232 link) a low pass filter is required (anti-aliasing) to filter all frequencies above half the sample rate, in this case the filter should filter out frequencies above 2.875kHz, hence because the system has a low frequency cut off of 0Hz (e.g. DC waveforms can be monitored) the system has an analogue bandwidth of 2.875 kHz. 

Clearly there is no reason why multiple scopes cannot be used, for example two scope programs can be executed in windows one could be configured to use COM1, the other COM2. Hardware can be connected to COM1, and other set of hardware connected to COM2. Hence up to 8 channels can be monitored simultaneously on one computer screen. Obviously the only limit is the number of serial ports the PC has and how many scope programs it is capable of running simultaneously (i.e. processor power). Also it is important to note that the chosen PIC has 8 input pins to the ADC, hence with minor modifications to the scope program (cut & paste drawing of waveforms, etc…), hardware (remove dip switches from port E), and embedded software (sample channel 1 to 8) eight channels could be monitored simultaneously (that’s 16 channels if two scopes are used), but at a reduced sample rate when all eight channels are enabled (unless using storage or real-time alternate mode).

Adding storage functionally to the scope was the last thing to be done, clearly this feature is not complete but good progress has been made as block diagrams of the communication protocol and frame structure were included in this report. It is important to relies that storage mode, should theoretically allow for faster sample rates which are not limited by the speed of the transport medium; e.g. the PIC reads 1000 readings from channel 1 at 20KHz then stops sampling and transfers the data to the PC using the storage mode frame structure (including CRC) via RS232, once ACK (Acknowledgement) is received from the PC the PIC starts sampling again. If NAK (Negative Acknowledgement) is received or a timeout occurs the PIC retransmits the frame. Clearly most of the ground work for implementing storage mode operation has been done, for example functions for writing to the RAM chip were successfully written and tested, and implementation can easily be achieved if more time was available.

Evidently the maximum sample rate when operating in storage mode is the speed of the ADC, this was calculated to be 43.63 kHz. Hence since frequencies above half the sample rate must be filtered (anti-aliasing) the actual maximum analogue bandwidth of the system is 21.815Hz (note f_low = 0Hz). Undoubtedly an external ADC with direct memory access makes it possible to monitor very high frequencies (e.g. AD9070 – 10bit, 100MSPS ADC), but these chips are expensive, hence the low cost of the design is lost. It is clear the following limits the maximum storage sampling rate: the maximum sampling speed of the ADC, time taken to send to RAM, and the amount of memory.

Overall progress has been good, although it has taken much longer than expected to complete certain aspects of the project (e.g. triggering of waveforms). The project was a success, real-time waveforms have been successfully displayed on a PC in real-time and it has been demonstrated how storage mode operation could be added to project to increase maximum sampling rate, even if the transport medium is slower than the sample rate.

This Web Page was last updated on Wednesday June 19, 2002