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