The MAS345 Multimeter

Introduction:

The Mastech MAS345 auto-ranging, and more importantly RS232-enabled, multimeter is a useful tool when it comes to data logging. In addition to the usual measurements, you can also attach an inexpensive temperature probe (a K-type thermocouple that may or may not be included with the meter when you buy it). This particular digital multimeter (DMM) is relatively inexpensive, retailing in and around the $50 mark.

The multimeter comes with a software package called DMM-View that allows you to connect to the multimeter and read or graph measured values. Unfortunately this software is not terribly flexible if you want to do anything out of the ordinary. (Some details about the capabilities of DMM-View can be found here).

Talking to the multimeter:

What would be really nice would be to hook the MAS345 up to PureData (PD) so that we can gain all the flexibility that PD offers. The first step in this direction is to check the specifications for the MAS345 so that we can communicate with it over the RS232C. These specs are listed in the table below (originally found here):

We might like to be able to poll the meter frequently for updated measurements but these specifications point out that if the meter is polled too often (more than once per second), the data returned becomes unreliable. This is true in practice -it seems that if you poll the meter too often, you end up polling it while it is responding to the previous request. This means truncated responses as the meter abandons writing out the current response and tries to respond to the new request.

The first step in creating a PD abstraction for this meter is to enable communications over the COM port. I’m using a cheap USB-COM adapter, so I had a quick look in the control panel to find the COM port number.

Finding the COM port number in windows

The abstraction centers around the comport object. The basic strategy on connection to the meter is to continuously read the meter each second. Results are stored within the abstraction. When a read request comes in, the stored value is returned immediately. (This might be an issue with time-critical applications where you need an instantaneous reading on request – with this approach, the values returned might be up to 1 second old).

Another option to read from the meter is to send in a readcontinuous message. When this is received, each time new data is read from the meter, the data is outputted from the abstraction (as if a read message was received).

Using the abstraction:

Here are the messages that are understood on the single input:

The code:

You’ll probably want to change something, so here’s a brief overview of the code. The first element is the routing of incoming messages. It’s all pretty straighforward from a PD point of view. The port, by default is 0, and all the parameters for talking to the meter (apart from the port) are stored neatly away in this part of the abstraction. When an open message comes in, the current port and all other parameters are sent to the comport.

Input routing

The next section of the code is the storage section for the unit, measurement and mode. Note that each receive their values wirelessly and are stored until a bang comes in on the $0-read wireless connection. When this bang is received, the values for unit, measurement and mode are sent to the outputs.

Storage of most recent measurements

The control section is definitely the most complicated (and could be made easier/better if I had the time – but here I am writing and not coding….). Essentially, each time the metronome fires, a 13 (Carraige return) is sent to the comport. This is how we poll the meter for its data. The specification says that any byte will do, so a CR is fine. The meter should then respond with 14 bytes of data which needs to be chopped up accordingly. Before we get to the chopping – I noticed that sometimes the most significant bit of each byte being returned from the meter was set for no particular reason. What this means is that sometimes the bytes coming from the meter were 128 too big. You’ll notice the moses object in there, catching all bytes >= 128 and subtracting 128 from them. I’m not entirely sure why this is happening but it’s sort of fixed. It might be worth keeping an eye on though.

Capturing and parsing returned data

A cycle object is then used to distribute the 14 bytes around to various bits of logic to interpret them and glue them together into the mode, measurement and unit. Each time a CR is received, it means that the end of the 14 byte response has been reached. Again, from time to time, a byte can be lost (very rarely). In order to allow synchronization to be re-established, each time a CR is received, the cycle object is reset to output 0 (the leftmost output). This means that if synch is lost and a CR is received in what the abstraction thinks is the middle of a message, the cycle object will be reset to 0, so at least the next message is likely to be read correctly.

Installation:

1. Grab the MAS345.zip file and extract it.
2. Place the extracted MAS345 folder into the ‘extras’ folder in the PureData program directory.
3. Start PD-extended
4. You need to tell PD where to find the MAS345 code. Go to the File menu and select File->Path->New and add a path to the new MAS345 folder
5. You should now be ready to use the MAS345 object. Create a new object type MAS345 into it. There’s a help file (just a small demo application similar to the one shown below) that you can get to by right-clicking on the new MAS345 object and selecting help.

A small demo:

Once you have the software installed, connect up the multimeter (check which COM port it is on). Go to the help file (as per step 5 in the installation instructions). When the demo patch loads up, you may want to change the port number to the number of the COM port where your DMM is located. Then:

1. Power up the multimeter
2. Connect to the multimeter by clicking on the message commented ‘click here first’.
3. Start continuous readings by clicking on the readcontinuous message.
4. Play around with the multimeter, watching the outputs change according to what mode the multimeter is in and what value it is reading.

The MAS345 reading DC voltage from a 9v battery

Conclusion:

That’s more or less it. Some items you might want to consider would be:

• Adjusting the frequency of automatic polling of the meter. At the moment polling is set to a frequency of one second. I’d imagine in applications where the multimeter is running for a long time and you don’t need per-second measurements, it might be worth reducing the frequency to save battery life in the multimeter.
• Looking at the padding of the measurement output. I’d do this myself, but I haven’t used the meter enough in all modes.
• Tidying the code. As usual, it’s written quickly – and not tested enough.
• Multi-multimeters – it should be possible to hook up multiple multimeters using one instance of the abstraction for each (each talking to its unique comport). I only have one MAS345 on a rather dodgy USB-COM adapter, so I can’t test this.
• All of this was written in windows. There’s nothing windows-unique about the abstraction, so it should be OK wherever PD-extended runs.

We have our multimeter connected to PD and access to all the goodies that provides. You could monitor temperature/voltage – get sent measurements/alarms – play sound as voltage changes. You could probably even build a rough networked version of a multimeter-based lie detector. I’d leave out the alligator clips unless you’re into that sort of thing though….