M300 Data Acquisition System

The M300 is a real time Data Acquisition System based on the QNX 4 Operating System (real time, UNIX like, POSIX certified) from QSSL using Photon as the Graphical User Interface (GUI). It runs on Pentium based systems with a minimum of 128 MB RAM, a mouse, and an accelerated video card. It is fast, versatile and has the potential to expand and take on new challenges. Most of the interfaces from the M20S0 system can be used with the M300. This allows the user to upgrade the chassis, CPU, OS software and M300 software while using all the existing M200 hardware. The M300 uses the same basic data format as the M200. It also has the same design philosophy as the M200, one version of the software is customizable in order to fit multiple users.

The M300 chassis can come in a variety of ways. Standard 14 slot rack mount systems for most users. For users which require a large number slots for their systems we use a 20 slot chassis. Small systems can be configured with 6-10 slots, for small platform and weight. Most M300 systems use a combinations of ISA and PCI passive backplane with a single CPU card.. Tiny systems can use PC104 plat form for even less space and weight requirements.

Click here for an image gallery of several different M300 display windows.

A Message from the Engineers

A Tribute to the M200

After years of trusted use the Model 200 Data Acquisition System (M200 DAS) was showing its age. Developed for the DOS operating system (OS), for the past 12 years the M200 DAS has hit several major limitations along the way.

  • A limit of 640K memory available for program execution and data structures.
  • No mouse support.
  • Command based system, no GUI interface.
  • Limited screen resolutions to EGA (640x350) or VGA (640x480).
  • Maximum of 5 colors (red, green, blue, black and white).
  • Limited connectivity support via Network cards for data transfer to other machines.
  • Minimal hard copy printing of M200 windows.
  • Separate applications for Data Acquisition and playback.

A little history in time

A few years back we started talking about the next generation of the DAS. What would our users like to see in the new DAS, we asked. More memory came to mind right away. User friendly wasn't far behind. Use existing hardware interfaces whenever possible. More colors and support the new graphics resolutions. Keep the same basic M200 data format. How about controlling the frequency of computations and displays? And, if we could send data during acquisition and playback to other systems, that would be just great.

Well, this is where the Model 300 Data Acquisition System (M300 DAS) comes in. A significant portion of time was dedicated to finding a suitable OS to host the M300. We knew from experience that none of the MS Windows products were a possibility. The widespread familiarity with Microsoft products would have been an asset to our deployment of products but they are not real time operating systems.  Some of the options we evaluated were abandoned immediately because of high cost concerns while other Operating Systems such as DOS were cheap but system limitations made them impractical choices. We quickly found that our challenge was to find a balance between functionality, performance and cost. At the time the business support for Linux was limited and it was not a real time operating system. Other Linux inspired solutions such as Lynx OS were real-time but after in house evaluations we realized they were unsuitable and began searching for alternate possibilities.

Finally we discovered QNX 4 by QSSL in Canada. We had them send us information about their products (this was back in 1995, the days when there was no Web). The system looked like it could do what we wanted but how were we going to make sure this was the one? QSSL was nice enough to let us evaluate their system. They even sent a package of cookies with the system and that is when we knew we had found the one!

Our first test was to prove the system could handle interrupts efficiently.  So we took an SEA System card and wrote a program to initialize the card and handle the interrupts.  We measured interrupt latency and were amazed with the efficiency.  We still had a little time left on our evaluation period so Lyle decided we should evaluate what we could do with 2D images.  This forced us to implement DMA operation in addition to the interrupts by using an added 2D Mono to acquire images. It took a few days, but we made it work. We knew we could handle DMA and interrupts beyond our expectations. The only question left was how difficult it will be to display the data. At the time, we tried X Window as the GUI. In no time, we added an X Windows application that would run 2D and display the images. This pretty much put to ease any concerns we had about the OS and we knew QNX 4 could do the job but we still had to pick the GUI!

There were three options available (QNX Windows, X Windows and Photon). QNX Windows was being discontinued. Mark that one off! We loved the idea of using a standard GUI like X Windows, but there were limited QNX 4 video drivers for X Windows. QSSL was putting all their efforts into developing Photon. Our choice was tough, but in the end we picked Photon after talking to several engineers at QSSL and getting a better picture of what was going on in this area.

So there you have it. We picked QNX 4 RT OS (UNIX-like, real-time POSIX certified) with the Photon GUI for our M300 DAS from QSSL (www.qnx.com). Yes, it costs a little more than DOS, but not as much as other operating systems we looked at. QNX also offers other goodies that we were looking for, such as TCP/IP and NFS.

Then, as luck would have it, Walter Strapp at MSC was looking to add a Forward Looking Radar data acquisition and display to the M200 system. We wanted to please our client, but the M200 just didn't have enough memory to handle this task. Since we had been playing around with QNX 4, we thought it could do the job. So we did our first project for QNX 4. Because of time constraints and against our better judgment, we wrote an application that was specific to the Forward Looking Radar. QNX 4 performed great along the way, as did our new software application. After this, AES came back to us and wanted to add the capability to have up/down/side antennas out of the Convair. No problem, we said. The work was started for this, but there was a great empty feeling. We knew there was a need for a new DAS, but at the same time, we were writing specific applications, that required software changes to add new instruments and capabilities to the system. We had gone away from one of the main design philosophies behind the M200 DAS. Before a lot of work was done, we changed our minds and started work on the M300 DAS.

Model 300 Data Acquisition System is born (circa November 1999)

So what sets the M300 DAS apart from the M200?

  • To start with, we don't have to deal with DOS anymore.
  • Finally we have a robust real time OS to work with and a GUI. Oh! Look a mouse!
  • We can now add as much memory to a system as we would like and be able to use it. Now we can dream!
  • Almost all existing M200 hardware interfaces will be supported by the M300. This saves our users from having to buy a new set of hardware interfaces.
  • We did away with the command interface. Our users will not have to learn/remember any more M200 commands.
  • The M200 data format still rules. We have made some small changes that do not violate the basic M200 data format (as you will see in the future). For example, all M300 buffers have a starting time as well as an ending time.
  • Support for larger screen resolutions. The M300 will start at 1024x768 and go up from there (1152x864, 1280x1024, 1600x1200).
  • We have a lot more than 5 colors! The user can set the desired number of colors for the video mode (256 colors, 16-bit color, 32-bit color). For speed constraints we will recommend staying at 256.
  • Interfacing with the M300 is simple and easy.
  • Similar text table setup as M200 software. Table names and contents are different than the M200 system. Sorry! We couldn't keep everything the same!
  • Integrated software modules for M300 (main application), M300 manager (m300m), M300 recording (m300r) and M300 broadcasting (m300b).
  • One click simple start operation. No complicated start sequence of different modules with corresponding parameters.
  • You can run up to 26 sessions of the M300 at the same time. Only the first session can be used for acquisition mode. All other sessions must use either playback or UDP mode.
  • Unlimited number of research projects configurations. User can select different configurations for the system, just by picking a different project.
  • Project history list in project menu.
  • File history list in file menu.
  • M300 system automatically loads last project used. All window positions are remembered.
  • Unlimited number of individual display windows. Each window can be resized, maximized, closed or minimized.
  • Currently three possible data sources: Acquisition, Playback and UDP (Universal Datagram Protocol from another M300 system).
  • One second buffer. Other synchronous buffers that are faster or slower than one second are possible.
  • Asynchronous buffers. The M300 asynchronous buffer can acquire any acquisition event (aside from master and slave events).
  • Each M300 buffer has a type to match the master acquisition event for the buffer.
  • New scheduling scheme with trigger, frequency and board. Primary and secondary triggers available.
  • Simple board setup with specific dialog windows for each board type. Board hierarchy presented in tree format for project.
  • Simple acquisition setup with dialog window. Acquisition and board hierarchy presented in tree format for project.
  • Simple buffer setup with dialog window. Buffer and acquisition hierarchy present in tree format for project.
  • The M300 DAS supports UDP data broadcast during acquisition or playback modes.
  • During playback mode the user can write data to M300 binary file.
  • Capability to playback data from an open growing file on another system over the network connection.
  • Maximum system frequency of 10,000 hz.
  • Individual computations can be scheduled at different frequencies.
  • Individual displays can be scheduled at different frequencies.
  • Capability to watch and alter any formula value.
  • Same ASCII file output capabilities as M200 with scheduling capability added.
  • Built in system status/health information available for acquisition mode.
  • Support for all of the existing M200 functions. New ones will be added as necessary.
  • New display types for Radar Reflectivity, Moving Air Mass, Hodograph and Skew T displays.
  • Improved Position display with wind barbs along track.
  • The M300 supports all the M200 math functions as well as some new ones.
  • Support for double, float, signed/unsigned long, signed/unsigned integer, signed/unsigned char and string data types.
  • All M300 windows have date and time information.
  • All M300 windows have a pause, grid toggle, print, properties and color buttons.
  • Technically unlimited Strip Charts and X vs. Y plots per window. The M200 limited the user to 3.
  • Enhanced capability to print any M300 window (printer output or bitmap file).
  • Data acquisition and playback support via same software package.
  • Capability to make upgrades to the M300 software to support more and more instruments with corresponding displays. The M200 development is halted due to severe memory limitations for executable source code and data structures.