Final Report: 13.0. Recommendations For Further Work


13.0. Recommendations For Further Work

13.1. Control Protocol

13.2. Storage Mode

13.3. Multiple Serial Ports

13.4. USB Transport Medium

13.5. Bootstrap

13.6. Virtual Channels

13.7. Data Logging

13.8. TCP/IP Internet Communications

13.9. Direct Modem to Modem Communication

13.10. Printing of Scope Display

13.11. An Alternative Method for Dealing with Aliasing

13.12. Taking Advantage of Aliasing

Clearly there is a lot of additional development work that can be done to improve the design of this low cost PC-based quad channel real-time / storage oscilloscope. This chapter will briefly highlight areas of the design that merits improvement and additional features to make the scope more powerful, reliable, flexible, and commercially marketability.

13.1. Control Protocol

Obviously the first thing that needs to be finished, is the control protocol allowing for the scope program to directly control the sample rate, enable / disable channels, real-time / storage mode, chop or alternate, etc… Sufficient details have been included in this report on how this might be achieved.

13.2. Storage Mode

Sample a finite number of samples storing them into RAM. Once the memory is full (or the preset number of samples has been reached) the PIC will stop sampling and transfer the data to the PC, when ACK (acknowledgement) is received from the PC the PIC will start sampling again. There is enough information contained in this report to implement this feature, clearly the scope program and PIC software needs modification.

13.3. Multiple Serial Ports

The PIC only has one hardware UART; hence one solution is to use the hardware UART plus a software UART (CCS C complier makes this easy). Two bytes are sent for per ADC reading, hence put the first byte on COM1 and the second on COM2, this will double the maximum real-time sampling rate (11.5 kHz max). Note the MAX232CPE chip is a dual RS232 line driver chip hence no extra hardware is required, allow the additional software UART will push the PIC to the limit (should be OK at 20MHz). If it turns out it is not practical to use a software UART, an additional hardware UART chip could be used, these chips are readily available and are reasonably priced.

13.4. USB Transport Medium

The USB port is ideal for this type of application (12 Mbps); this takes away the RS232 bottleneck providing faster real-time sample rates. Note the USB throughput if far faster than the PICs ADC (43.63 ksps) hence this is the new bottleneck of the system. There is no need for storage mode, as the USB throughput is capable of transmitting a sample rate up to 600 kHz (12,000,000/20) in real-time, using external ADC.

Note the 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, hence a dedicated PIC maybe required to deal with USB communication, while another does the sampling. Note that USB communication protocol is packet based (lets other devices share the same link) hence the actual throughput will be less than stated above. Note the scope program is designed to flexible, and should be easy to integrated with the USB standard, actually Microsoft probably has a standard C++ plug-in object available for visual C++ designed for letting C++ programmers (e.g. the scope program) use the USB port without total knowledge of the USB communication protocol (e.g. automatically converts into correct packets). Unfortunately interfacing the PIC will be a completely different story.

13.5. Bootstrap

The chosen PIC can protect blocks of program memory, hence a bootstrap program can be written to check the serial interface before calling the main program. If a certain block of characters are received during bootstrap, it moves into program mode, using a bidirectional communications protocol (RTS, ACK, NAG, etc…) a new program can be download from the PC directly into program memory, when download is complete the new program is called. This offers greater product flexible as software updates (bug fixes, new features) can be downloaded free of charge and download directly into the product using the same serial interface and software used to display the waveforms (i.e. the scope program).

Microchip application note [J6] will fully describe how to implement this, including full source code.

13.6. Virtual Channels

It is recommended that the scope program should have up to four user configurable virtual channels, that’s a total of 8 channels. Each virtual channel can be configured as follows: CH1 + CH2 or CH1 x CH2 or CH1 – CH2 or CH1 / CH2 etc… This makes the scope program more versatile increasing its usefulness, for example monitoring of RS485 / RS422 serial communication is now possible. RS485 / RS422 works on the principal of differential voltages between two cables twisted together (good noise immunity), hence two oscilloscope channels (four for RS422) could be used and the scope program will automatically add the traces together creating a new trace say CH5 (virtual channel 1).

This is extremely easy to achieve, it is only matter of creating four more traces the same as was done for channels 1 to 4 (e.g. cut & paste makes life easy). Instead of filling the arrays for these traces using the communication protocol, the program continuously scans though each real channel array multiply, adding, dividing or subtracting channels together (e.g. whatever the user has specified for each virtual trace) filling the virtual trace arrays.

13.7. Data Logging

The scope program already has dummy dialog controls for this feature, basically real-time data is streamed to disk, allowing the user to play back the recorded data in real-time, manually scroll through the data, and email the data to a colleague anywhere in world. For example this feature would be useful for monitoring of an ECG signal, where the raw data can be email to a doctor for diagnosis.

This feature is easy to implement basically every character that is received from the serial port is dumped into a file, and when playing back the data, the program runs through the recorded data at the same rate it was originally sampled at (perhaps the sample rate combo box could still be operational, allowing for a slowed or speeded up view of the data).

13.8. TCP / IP Internet Communications

Remote monitoring / control of oscilloscope from anywhere in world, for example the machine actually connected to the scope hardware (running in slave mode) relays real-time data through the internet using the TCP / IP internet protocol, the scope program on the other end (master program), receives the data and draws the waveforms as normal. The scope program operating in slave mode has its controls disabled, hence only the master scope program controls the PIC, via the internet and via the slave scope program.

Problem the internet (unless using broadband technology, e.g. ASDL, fibre optic) is slow and commonly suffers from net congestion, hence this feature is only useful for slow sampling rates, unless storage mode is used. For example an ECG signal only requires a sample rate of 120 Hz, clearly the internet is capable of transferring this data in real-time without any problems, hence a doctor can remotely diagnosis an ECG signal in real-time.

13.9. Direct Modem to Modem Communication

The master scope program dials the slave scope program and a direct communication link is established. Once at direct modem link is established the communication protocol between the remote scope programs are exactly the same as with a direct like to the PIC, hence the only operation of the slave program during this time is to relay the data from the PIC to the master scope program and visa versa.

This feature is easy to implement, basically two additional functions is required one to setup the scope program as a master (dial user configurable number, real-time, storage and control protocols unchanged) and the other to setup the scope program as slave (wait for connection and once connection is established rely data from the PIC to the master visa versa).

13.10. Printing of Scope Display

The scope program should be able to print the scope display directly to the system printer. Some work has already been done in this area, for example configuration of the printer is currently possible and code for printing exists along with a header and footer. The only thing that remains to be completed is the drawing of the scope display, clearly the simplest way of achieving this is by copying the bitmap directly to the printer output CDC, but this is not ideal, as this would not contain any information about the selected time-base, voltage scales (this is essential), and the screen resolution (source of bitmap) could be much lower (this is likely) than that of the printer hence producing a poor quality printout.

Obviously the grid and traces need to be redrawn on the printer output CDC, this is simple as the code is exactly the same as that which draws the grid and traces to the screen (hence put cut & paste to good use), allow the size of the page is different to that of the screen hence don’t forget to detect the resolution of the printer.

13.11. An Alternative Method for Dealing with Aliasing

Generally a low-pass filter is used to filter out frequencies above half the sample rate. Instead of filtering out aliased signals, a hardware circuit can be used to detect the actual frequency of the waveform being monitored. The PIC can then transmit the actual frequency of the waveform to the scope program. The scope program can then software calculate the frequency of the sampled waveform and if the two frequencies do not match the scope program knows that the sampled waveform is an alias.

Figure 13.11a. Frequency detection circuit

Figure 13.11a shows how a simple detection circuit could be made. A Schmitt-Triggered inverter is used to generate squarewaves at the same frequency of the original signal which is then passed through a frequency divider circuit which decreases the frequency by 256. The output of the detection circuit is connected directly to a Schmitt-triggered input on the PIC which is configured to interrupt the PIC. Using a real-time timer the frequency of the signal can be calculated and transmitted to the scope program.

Figure 13.11b. Divide by 256 circuit

The reason why the divider circuit (figure 13.11b) is required is to reduce the processing load on the PIC. For example if the divide by 256 was not there, the PIC would be interrupted 5000 times a second instead of 19.5 for a 5 KHz signal. If the PIC was interrupted 5000 times a second, normal operation of the PIC would be severally affected. If extremely large frequencies are possible (> 1MHz) the frequency divider should be increased.

13.12. Taking Advantage of Aliasing

Using the frequency detection circuit shown in figure 13.12a it maybe possible to monitor periodical waveforms that have a frequency much higher than the sample rate. The idea behind this theory is that at certain frequencies aliased waveforms are the same as the input waveform expect for the frequency (as seen during testing). Therefore with some software processing it is possible to redraw the waveform at the correct time-base using the hardware frequency detection circuit as a guild. This technique will not work for random waveforms for example sound-waves, only periodical waveforms which 9 times out of 10 is what an engineer uses an oscilloscope to monitor.

This technique could allow for waveforms up to 1 MHz (or above) to be monitored using this PC based oscilloscope. If more time was available it would be nice to investigate this theory further.

Final Year Project

Content Page

Colin's Home Page

This Web Page was last updated on Thursday July 04, 2002

Home About me National Record Of Achievement Hobbies / Interests Guest Book Contact Me Links Snooker Amateur Radio Site Map

This website is best viewed by Microsoft Internet Explorer 6.0 at a resolution of 1024 x 768