I appreciate you forwarding this to me. However, I find most of what is described is above my head; also it may require Windows I do not have.
I have been distracted by another issue for a while now, but that is solved, so I intend to get back to the DMM shortly. The last effort I put into it was using some of the Python code I found. It seemed to acquire data correctly most of the time, except randomly the first data field was empty, or at least equal to zero. I hope to test for that problem and perhaps that will be a work-around. I will relate my progress when I have something definitive. -Denis On Tue, Mar 6, 2018 at 12:09 PM, wes <p...@the-wes.com> wrote: > 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 > _______________________________________________ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
