[PLUG] Serial communication with dmm

wes plug at the-wes.com
Tue Mar 6 20:09:06 UTC 2018


Today I chanced upon "USPPcap" - a utility designed to capture traffic on
USB ports.

http://desowin.org/usbpcap/tour.html

It seems to me, since the Windows-based software for this thing works well,
and you have a USB->serial adapter, this utility could potentially be used
to monitor the traffic on a successful meter read, which could then be used
to re-create those steps in whatever other environment you'd like to use.

-wes

On Sun, Jan 7, 2018 at 5:13 PM, Denis Heidtmann <denis.heidtmann at gmail.com>
wrote:

> The meter schematic I have shows two opto-isolators connected to the serial
> pins.  The output from the meter is an emitter follower driving the RxD pin
> and the emitter resistor connected to RTS.  The collector is connected to
> DTR.  The input to the meter drives an LED in series with a 3.3K resistor,
> TxD (+) to GND .  Does this explain the RTS being driven low?
>
> The protocol I have seen documented is:
>
> data format: 7n2 at 600 baud (7 bits, no parity, 2 stop bits).
> Control lines:
>    DTR and RTS lines are used to power the TX line: RTS is clear
>    for -12 supply; DTR is set for +12 supply. Data transmission is
>    solicited sending whatever character to the RX line.
> Data string format:
>    MAS-345 sends a 14 bytes string with:
>          <mode>< ><sign><value>< ><units><return>
>    <mode>:  two bytes with the oerating mode: DC, AC, OH, CA, TE ...
>    <sign>:  one byte with - or space
>    <value>: five bytes with four digits and one decimal dot.
>    <units>: four bytes with the units: mV, A, kOhm, nF ...
>    <return>: '\r'
>    One space is inserted between <mode> and <sign>, one between
>    <value> and <units>.
> The data string (without the '\r') is sent to the output device.
>
> The changes I made to the code to get some results were line 116 timeout
> changed from 0.1 to 3.0 and  commented out 129,  self.s.setTimeout(1) since
> it generated an error msg. indicating serial had no such object.   These
> changes gave me output if the meter was set at dc volts, otherwise an
> instruction to change it to dc volts.   Later I changed line 56 to make
> debug = True.  This gave me a listing of the what was coming from the meter
> (repeatedly), matching the above listing.
>
> So for starters I need to get it to poll the meter no more rapidly than
> 1/sec.  But I guess even in its wounded condition I could try to see if it
> will work with the usb-serial adapter.
>
> -Denis
>
> On Sun, Jan 7, 2018 at 2:18 PM, Denis Heidtmann <denis.heidtmann at gmail.com
> >
> wrote:
>
> > My goal is to be able to get data from the dmm using my laptop, which has
> > only USB.  I have an RS-232--USB adapter.  Eventually I want to make the
> > choices more friendly.
> >
> > Later today I will study the details of your observations.  The protocol
> I
> > have seen described elsewhere says the host needs to send a single byte
> > (H?) to get the dmm to send one reading.  I had to change two time values
> > and remove the setTimeout line to get it to work.  At present it locks
> the
> > meter for some time.  I expect that is because the host is sending bytes
> > too fast, causing the meter to try to respond before it is ready, a
> > difficulty I saw referenced in another description of how to deal with
> this
> > meter.
> >
> > Thanks for looking at the code.
> >
> > -Denis
> >
> > On Sun, Jan 7, 2018 at 12:35 PM, Galen Seitz <galens at seitzassoc.com>
> > wrote:
> >
> >> On 01/07/18 10:04, Denis Heidtmann wrote:
> >> >>
> >> >> On Mon, Jan 1, 2018 at 11:46 AM, Denis Heidtmann <
> >> >> denis.heidtmann at gmail.com>
> >> >> wrote:
> >> >>
> >> >>> I am looking into ways to examine the serial traffic to/from my dmm.
> >> >>
> >> > <snip>
> >> >
> >> > I found a python script intended to interface with the mas-345:
> >> > https://github.com/markrages/py_test_interface
> >> > https://github.com/markrages/py_test_interface/blob/master/mas345.py
> >> >
> >> > I gave it a try on my desktop (which has a serial port).  To get it to
> >> run
> >> > I changed a couple of parameters and commented out one that was
> >> generating
> >> > a no-such-parameter error.  Then I put it into debug mode so I could
> see
> >> > the traffic from the meter.  The good news is it appears that the
> meter
> >> > does report values as the documented protocol indicates.  How the
> >> > communication is done is buried in the "serial" Python module. Someone
> >> who
> >> > understands Python could learn from this; I cannot.
> >>
> >> I've used the python serial module a few times.  Looking at that code, I
> >> see a few things that strike me as unusual.  First is RTS is
> >> cleared(line 125).  Normally both DTR and RTS would be set during serial
> >> communication.  The second thing is that the meter apparently requires
> >> the host to send 14 null characters(line 138) in order to cause it to
> >> send its measurement data.  Finally, requiring two stop bits(line 117)
> >> is unusual.  (Note that two stop bits and seven bit data is equivalent
> >> to one stop bit and including a mark parity bit in eight bit data.)
> >>
> >> Since its working with the python script, I suggest you continue using
> >> python.  It's not as hard as it might at first appear.  I don't recall
> >> your goal for this, but if you look at lines 169-197, I think you'll
> >> begin to see how it might be modified to suit you.
> >>
> >> galen
> >> --
> >> Galen Seitz
> >> galens at seitzassoc.com
> >> _______________________________________________
> >> PLUG mailing list
> >> PLUG at pdxlinux.org
> >> http://lists.pdxlinux.org/mailman/listinfo/plug
> >>
> >
> >
> _______________________________________________
> PLUG mailing list
> PLUG at pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug
>



More information about the PLUG mailing list