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 <[email protected]>
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 <[email protected]>
> wrote:
>
>> On 01/07/18 10:04, Denis Heidtmann wrote:
>> >>
>> >> On Mon, Jan 1, 2018 at 11:46 AM, Denis Heidtmann <
>> >> [email protected]>
>> >> 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
>> [email protected]
>> _______________________________________________
>> PLUG mailing list
>> [email protected]
>> http://lists.pdxlinux.org/mailman/listinfo/plug
>>
>
>
_______________________________________________
PLUG mailing list
[email protected]
http://lists.pdxlinux.org/mailman/listinfo/plug
