Re: [PLUG] Serial communication with dmm
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 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 > > 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: > > < >< > > >: two bytes with the oerating mode: DC, AC, OH, CA, TE ... > >: one byte with - or space > >: five bytes with four digits and one decimal dot. > >: four bytes with the units: mV, A, kOhm, nF ... > >: '\r' > >One space is inserted between and , one between > > and . > > 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 > > > 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. > > >> >> > > >> > > > >> > > > >> > 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
Re: [PLUG] Serial communication with dmm
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 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: > < >< > >: two bytes with the oerating mode: DC, AC, OH, CA, TE ... >: one byte with - or space >: five bytes with four digits and one decimal dot. >: four bytes with the units: mV, A, kOhm, nF ... >: '\r' >One space is inserted between and , one between > and . > 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 > > 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 > > 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. > >> >> > >> > > >> > > >> > 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 no
Re: [PLUG] serial communication with dmm
Someone here, probably Wes, thought me embarrassing lesson: http://lmgtfy.com/?q=python+crash+course Put one/two day into learning basic python data types and syntax. It will be worth it, I guarantee it. T On Jan 15, 2018 6:57 PM, "Denis Heidtmann" wrote: > Well, I have solved the issue of "mult=self.units.strip()+' '[0]: > TypeError: can't concat bytes to int". It needs parentheses, which the > original code had. Now the code runs, but, alas, now it does not report > the readings from the meter. Since I really do not understand > object-oriented python, I am at a loss. It seems to me that this format is > inadequate and inappropriate for schooling a coding novice on such things, > so I will see what I help I can get in person. Thanks for all who have had > to suffer through this. > > -Denis > > On Sun, Jan 14, 2018 at 6:30 PM, Denis Heidtmann < > denis.heidtm...@gmail.com> > wrote: > > > Last discussion on this issue I mentioned a python program I found. I > > have since put the program in Spyder using Python3. I had to make a > number > > of changes to accommodate the change to 3. The latest is that I see that > > the readings are available to the program although parsing the data is > > running into difficulty associated, I believe, with Python3's fussiness > > with bytes, strings, etc. (The data I see is via some print statements > > stuck in the code.) > > > > line 72: originally it had > > > > mult=self.units.strip()+' '[0] > > TypeError: can't concat bytes to int > > > > I tried: > > mult=self.units.strip()+' '.encode()[0] > > > > and > > mult=self.units.strip()+b' '[0] > > > > to no avail. > > > > Note: > > data = b'DC -0.000 V\r' > > type data = > > 01234567890123456789 > > type units = > > > > But the good news is that when I changed the reading on the meter the > > value in data changed accordingly. So I see the issue now as one of > > knowing how to fix the Python so that it parses the data correctly, > rather > > than an issue of how to communicate with the dmm. > > > > BTW, I see no way to change the manufacture's sw running under Windows > to > > look at the usb, which is what I need to test the usb interface under > > Windows. I will explore the usb using Linux, which is the ultimate > goal. > > > > > ___ > 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
Re: [PLUG] serial communication with dmm
Well, I have solved the issue of "mult=self.units.strip()+' '[0]: TypeError: can't concat bytes to int". It needs parentheses, which the original code had. Now the code runs, but, alas, now it does not report the readings from the meter. Since I really do not understand object-oriented python, I am at a loss. It seems to me that this format is inadequate and inappropriate for schooling a coding novice on such things, so I will see what I help I can get in person. Thanks for all who have had to suffer through this. -Denis On Sun, Jan 14, 2018 at 6:30 PM, Denis Heidtmann wrote: > Last discussion on this issue I mentioned a python program I found. I > have since put the program in Spyder using Python3. I had to make a number > of changes to accommodate the change to 3. The latest is that I see that > the readings are available to the program although parsing the data is > running into difficulty associated, I believe, with Python3's fussiness > with bytes, strings, etc. (The data I see is via some print statements > stuck in the code.) > > line 72: originally it had > > mult=self.units.strip()+' '[0] > TypeError: can't concat bytes to int > > I tried: > mult=self.units.strip()+' '.encode()[0] > > and > mult=self.units.strip()+b' '[0] > > to no avail. > > Note: > data = b'DC -0.000 V\r' > type data = > 01234567890123456789 > type units = > > But the good news is that when I changed the reading on the meter the > value in data changed accordingly. So I see the issue now as one of > knowing how to fix the Python so that it parses the data correctly, rather > than an issue of how to communicate with the dmm. > > BTW, I see no way to change the manufacture's sw running under Windows to > look at the usb, which is what I need to test the usb interface under > Windows. I will explore the usb using Linux, which is the ultimate goal. > > ___ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Serial communication with dmm
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: < >< > : two bytes with the oerating mode: DC, AC, OH, CA, TE ... : one byte with - or space : five bytes with four digits and one decimal dot. : four bytes with the units: mV, A, kOhm, nF ... : '\r' One space is inserted between and , one between and . 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 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 > 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. >> >> >> > >> > >> > 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
Re: [PLUG] Serial communication with dmm
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 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. > >> > > > > > > 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
Re: [PLUG] Serial communication with dmm
I am indeed seeing data values. The options the sw provides are not ideal, at least as I am able to understand it, but data does come across. I would need to understand more (i.e., something) about pyserial to make the change to ttyUSB0, but all this is more progress than I have had in all the time spent beating on this. -Denis On Sun, Jan 7, 2018 at 11:37 AM, Russell Senior wrote: > Do you mean you are seeing data values from the DMM? If so, does the same > software work with the USB-serial cable? You might need to modify the code > to use /dev/ttyUSB0 instead of /dev/ttyS0. > > On Jan 7, 2018 10:04 AM, "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. > > > > > 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. > > -Denis > ___ > 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
Re: [PLUG] Serial communication with dmm
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. >> > > > 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
Re: [PLUG] Serial communication with dmm
Do you mean you are seeing data values from the DMM? If so, does the same software work with the USB-serial cable? You might need to modify the code to use /dev/ttyUSB0 instead of /dev/ttyS0. On Jan 7, 2018 10:04 AM, "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. > 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. -Denis ___ 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
Re: [PLUG] serial communication with dmm (was com port in guest to usb in host (virtual box))
I'm a nomad. Let's see how this week turns out. I may have some time on Friday. You can always email me off list. I'll call or text you later when I have more info about my availability. -wes On Mon, Jan 1, 2018 at 3:30 PM, Denis Heidtmann wrote: > Fantastic, Wes! My feeble abilities need lots of help. Where are you > located? I am on the west side of Portland, not far from the zoo. I guess > posting my phone number here is not too risky. 2972837. > > -Denis > > On Mon, Jan 1, 2018 at 12:36 PM, wes 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. > The > > > arrangement I think would be the most useful to examine is with the > > mfg.'s > > > sw running in the win2k guest in the desktop. This arrangement is the > > only > > > one that successfully communicates with the dmm. > > > > > > I hope (assume?) that a linux program running simultaneously in the > host > > > would be able to capture the traffic. Is this true? > > > > > > I have found the program jpnevulator. It seems to me that it could > > perform > > > the traffic monitoring function, but since there is a lot about serial > > > communications that I do not understand I could be mistaken. In the > read > > > mode will it capture the traffic in both directions (between the > windows > > sw > > > and the dmm), or must it be the recipient of the traffic, thereby > > removing > > > the windows sw from the interaction? > > > > > > > > I've been following this thread with interest. I've been thinking all > > along, "wouldn't it be great if you could just monitor the bits on the > > serial port?" This post struck me with inspiration: what you're looking > for > > is the equivalent of tcpdump for serial. That seems like something a lot > of > > people would ask about, so I googled just that: "tcpdump for serial". And > > that returned a lot of relevant pages, including this one: > > > > https://unix.stackexchange.com/questions/12359/how-can-i- > > monitor-serial-port-traffic > > > > which points us to: > > > > http://freshmeat.net/projects/linuxserialsniffer/ > > > > as well as jpnevulator. > > > > There's a lot of other interesting talk in that thread, and links to > other > > threads with other educational material. > > > > -wes > > > > > > > > > > > If this whole idea is ill-founded there is Tomas' instrument. However > I > > > did not see in the documentation that it was capable of any decoding. > > How > > > do I convert a train of pulses to a sequence of bytes and know which > end > > > sent them? > > > > > > > I am interested enough in your endeavor that I would like to get my hands > > on it. If this sounds agreeable to you, please let me know and we can set > > up a time to work on it together. > > > > -wes > > ___ > > 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
Re: [PLUG] serial communication with dmm (was com port in guest to usb in host (virtual box))
Fantastic, Wes! My feeble abilities need lots of help. Where are you located? I am on the west side of Portland, not far from the zoo. I guess posting my phone number here is not too risky. 2972837. -Denis On Mon, Jan 1, 2018 at 12:36 PM, wes 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. The > > arrangement I think would be the most useful to examine is with the > mfg.'s > > sw running in the win2k guest in the desktop. This arrangement is the > only > > one that successfully communicates with the dmm. > > > > I hope (assume?) that a linux program running simultaneously in the host > > would be able to capture the traffic. Is this true? > > > > I have found the program jpnevulator. It seems to me that it could > perform > > the traffic monitoring function, but since there is a lot about serial > > communications that I do not understand I could be mistaken. In the read > > mode will it capture the traffic in both directions (between the windows > sw > > and the dmm), or must it be the recipient of the traffic, thereby > removing > > the windows sw from the interaction? > > > > > I've been following this thread with interest. I've been thinking all > along, "wouldn't it be great if you could just monitor the bits on the > serial port?" This post struck me with inspiration: what you're looking for > is the equivalent of tcpdump for serial. That seems like something a lot of > people would ask about, so I googled just that: "tcpdump for serial". And > that returned a lot of relevant pages, including this one: > > https://unix.stackexchange.com/questions/12359/how-can-i- > monitor-serial-port-traffic > > which points us to: > > http://freshmeat.net/projects/linuxserialsniffer/ > > as well as jpnevulator. > > There's a lot of other interesting talk in that thread, and links to other > threads with other educational material. > > -wes > > > > > > If this whole idea is ill-founded there is Tomas' instrument. However I > > did not see in the documentation that it was capable of any decoding. > How > > do I convert a train of pulses to a sequence of bytes and know which end > > sent them? > > > > I am interested enough in your endeavor that I would like to get my hands > on it. If this sounds agreeable to you, please let me know and we can set > up a time to work on it together. > > -wes > ___ > 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
Re: [PLUG] serial communication with dmm (was com port in guest to usb in host (virtual box))
On Mon, Jan 1, 2018 at 11:46 AM, Denis Heidtmann wrote: > I am looking into ways to examine the serial traffic to/from my dmm. The > arrangement I think would be the most useful to examine is with the mfg.'s > sw running in the win2k guest in the desktop. This arrangement is the only > one that successfully communicates with the dmm. > > I hope (assume?) that a linux program running simultaneously in the host > would be able to capture the traffic. Is this true? > > I have found the program jpnevulator. It seems to me that it could perform > the traffic monitoring function, but since there is a lot about serial > communications that I do not understand I could be mistaken. In the read > mode will it capture the traffic in both directions (between the windows sw > and the dmm), or must it be the recipient of the traffic, thereby removing > the windows sw from the interaction? > > I've been following this thread with interest. I've been thinking all along, "wouldn't it be great if you could just monitor the bits on the serial port?" This post struck me with inspiration: what you're looking for is the equivalent of tcpdump for serial. That seems like something a lot of people would ask about, so I googled just that: "tcpdump for serial". And that returned a lot of relevant pages, including this one: https://unix.stackexchange.com/questions/12359/how-can-i- monitor-serial-port-traffic which points us to: http://freshmeat.net/projects/linuxserialsniffer/ as well as jpnevulator. There's a lot of other interesting talk in that thread, and links to other threads with other educational material. -wes > If this whole idea is ill-founded there is Tomas' instrument. However I > did not see in the documentation that it was capable of any decoding. How > do I convert a train of pulses to a sequence of bytes and know which end > sent them? > I am interested enough in your endeavor that I would like to get my hands on it. If this sounds agreeable to you, please let me know and we can set up a time to work on it together. -wes ___ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] serial communication with dmm (was com port in guest to usb in host (virtual box))
If you decide that you need to make the measurements - there is Bitscope logic http://bitscope.com/software/logic/ application which should be able to display and decode the serial signal for you from the probes. I never needed/used it with the bitscope, but it looks legit enough within the speed and capture memory limitations of the ancient bitscope HW. My bitscope has 4 analog channels which should be enough to cover your high swing serial port signals. It sure will take some time to setup, use, debug your problem, but it should be a lot of HW fun. If you have the time. Tomas On Mon, 2018-01-01 at 11:46 -0800, Denis Heidtmann wrote: > I am looking into ways to examine the serial traffic to/from my > dmm. The > arrangement I think would be the most useful to examine is with the > mfg.'s > sw running in the win2k guest in the desktop. This arrangement is > the only > one that successfully communicates with the dmm. > > I hope (assume?) that a linux program running simultaneously in the > host > would be able to capture the traffic. Is this true? > > I have found the program jpnevulator. It seems to me that it could > perform > the traffic monitoring function, but since there is a lot about > serial > communications that I do not understand I could be mistaken. In the > read > mode will it capture the traffic in both directions (between the > windows sw > and the dmm), or must it be the recipient of the traffic, thereby > removing > the windows sw from the interaction? > > If this whole idea is ill-founded there is Tomas' > instrument. However I > did not see in the documentation that it was capable of any > decoding. How > do I convert a train of pulses to a sequence of bytes and know which > end > sent them? > > I appreciate any advice. > > -Denis > > On Fri, Dec 29, 2017 at 6:54 PM, Denis Heidtmann il.com> > wrote: > > > > > I just ran the mfg. sw in the vb win2k guest. I then checked the > > serial > > parameters in the host. I then ran sigrok-cli --driver > > mastech-mas345:conn=/dev/ttyS0 --samples 10 in the host after > > shutting down > > the guest. Same no-response result. This would seem to rule out > > the > > possibility that the serial parameters are wrong. > > > > -Denis > > > > > > > > On Fri, Dec 29, 2017 at 2:44 PM, Denis Heidtmann < > > denis.heidtm...@gmail.com> wrote: > > > > > > > > I made the measurements with my 'scope. The voltages and > > > waveforms are > > > identical comparing DTR, RTS (also RXD), although I am surprised > > > a little > > > that the pulses on DTR are as large as they are: 2.4V > > > swing. Must be some > > > resistance in the supply to the drain. But the level is up at > > > 11.6V, so > > > those 2.4V drops cannot matter. The signals on the RXD pin are > > > -3.6 to > > > +8.2V for both the mfg. sw and sigrok. > > > > > > So no explanation yet, and hence no solution. Is there a way to > > > examine > > > the serial parameters the mfg. sw uses? Perhaps the docs on the > > > protocol > > > are in error. > > > > > > On Fri, Dec 29, 2017 at 9:17 AM, Denis Heidtmann < > > > denis.heidtm...@gmail.com> wrote: > > > > > > > > > > > I will make those measurements, but I am doubtful it will show > > > > anything. The schematic I have shows DTR to be the collector > > > > and RTS to be > > > > the low end of the emitter resistor of the output NPN. I did > > > > see solid > > > > pulses on the emitter with sigrok. But perhaps DTR and/or RTS > > > > are pulsed > > > > when they should not be. It is too bad my 'scope has limited > > > > record length > > > > and no way to store the data off the 'scope. > > > > > > > > On Thu, Dec 28, 2017 at 11:42 PM, Russell Senior < > > > > russ...@personaltelco.net> wrote: > > > > > > > > > > > > > > Have you measured the voltages on DTR and RTS during the > > > > > runs? > > > > > > > > > > Try it with sigrok and with the vendor software and see if > > > > > there is a > > > > > difference in those values. > > > > > > > > > > On Thu, Dec 28, 2017 at 9:51 PM, Denis Heidtmann > > > > > wrote: > > > > > > > > > > > > This saga continues. > > > > > > > > > > > > On the laptop with a usb-serial adapter I got to the point > > > > > > where the > > > > > > commands: > > > > > > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --show > > > > > > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --scan > > > > > > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 -- > > > > > > samples 10 > > > > > > > > > > > > behave as expected except the last one returns no data. I > > > > > > was > > > > > advised to > > > > > > > > > > > > try using these same commands on the desktop which has an > > > > > > RS232 port, > > > > > thus > > > > > > > > > > > > removing the usb-serial adapter from the picture. Good > > > > > > idea. > > > > > > > > > > > > After just guessing what serial port to use, I run the > > > > > > following > > > > > command: > > > > > > > > > > > > > > > > > > sig
Re: [PLUG] serial communication with dmm (was com port in guest to usb in host (virtual box))
I am looking into ways to examine the serial traffic to/from my dmm. The arrangement I think would be the most useful to examine is with the mfg.'s sw running in the win2k guest in the desktop. This arrangement is the only one that successfully communicates with the dmm. I hope (assume?) that a linux program running simultaneously in the host would be able to capture the traffic. Is this true? I have found the program jpnevulator. It seems to me that it could perform the traffic monitoring function, but since there is a lot about serial communications that I do not understand I could be mistaken. In the read mode will it capture the traffic in both directions (between the windows sw and the dmm), or must it be the recipient of the traffic, thereby removing the windows sw from the interaction? If this whole idea is ill-founded there is Tomas' instrument. However I did not see in the documentation that it was capable of any decoding. How do I convert a train of pulses to a sequence of bytes and know which end sent them? I appreciate any advice. -Denis On Fri, Dec 29, 2017 at 6:54 PM, Denis Heidtmann wrote: > I just ran the mfg. sw in the vb win2k guest. I then checked the serial > parameters in the host. I then ran sigrok-cli --driver > mastech-mas345:conn=/dev/ttyS0 --samples 10 in the host after shutting down > the guest. Same no-response result. This would seem to rule out the > possibility that the serial parameters are wrong. > > -Denis > > > > On Fri, Dec 29, 2017 at 2:44 PM, Denis Heidtmann < > denis.heidtm...@gmail.com> wrote: > >> I made the measurements with my 'scope. The voltages and waveforms are >> identical comparing DTR, RTS (also RXD), although I am surprised a little >> that the pulses on DTR are as large as they are: 2.4V swing. Must be some >> resistance in the supply to the drain. But the level is up at 11.6V, so >> those 2.4V drops cannot matter. The signals on the RXD pin are -3.6 to >> +8.2V for both the mfg. sw and sigrok. >> >> So no explanation yet, and hence no solution. Is there a way to examine >> the serial parameters the mfg. sw uses? Perhaps the docs on the protocol >> are in error. >> >> On Fri, Dec 29, 2017 at 9:17 AM, Denis Heidtmann < >> denis.heidtm...@gmail.com> wrote: >> >>> I will make those measurements, but I am doubtful it will show >>> anything. The schematic I have shows DTR to be the collector and RTS to be >>> the low end of the emitter resistor of the output NPN. I did see solid >>> pulses on the emitter with sigrok. But perhaps DTR and/or RTS are pulsed >>> when they should not be. It is too bad my 'scope has limited record length >>> and no way to store the data off the 'scope. >>> >>> On Thu, Dec 28, 2017 at 11:42 PM, Russell Senior < >>> russ...@personaltelco.net> wrote: >>> Have you measured the voltages on DTR and RTS during the runs? Try it with sigrok and with the vendor software and see if there is a difference in those values. On Thu, Dec 28, 2017 at 9:51 PM, Denis Heidtmann wrote: > This saga continues. > > On the laptop with a usb-serial adapter I got to the point where the > commands: > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --show > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --scan > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --samples 10 > > behave as expected except the last one returns no data. I was advised to > try using these same commands on the desktop which has an RS232 port, thus > removing the usb-serial adapter from the picture. Good idea. > > After just guessing what serial port to use, I run the following command: > > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --scan > The following devices were found: > mastech-mas345 - MASTECH MAS345 with 1 channel: P1 > > This is the same response I got on the laptop. > > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --show > mastech-mas345 - MASTECH MAS345 with 1 channel: P1 > Supported driver options: > conn > serialcomm > Supported configuration options: > > This is the same response I got on the laptop. > > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --samples 10 > > [no response except the usual ~10 second delay] > > This is the same response I got on the laptop. RATS! > > This eliminates the usb-serial device from the picture. > > Recall that when running --samples 10 command on the laptop I was able to > detect pulses on the serial line consistent (in a general sense) with a > response from the dmm. Also recall that running the mfg. sw under windows > on the desktop showed flawless communication. > > finally, I report: > stty -F /dev/ttyS0 -a speed 600 baud; rows 0; columns 0; line = 0; > intr = ; quit = ;
Re: [PLUG] serial communication with dmm (was com port in guest to usb in host (virtual box))
I just ran the mfg. sw in the vb win2k guest. I then checked the serial parameters in the host. I then ran sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --samples 10 in the host after shutting down the guest. Same no-response result. This would seem to rule out the possibility that the serial parameters are wrong. -Denis On Fri, Dec 29, 2017 at 2:44 PM, Denis Heidtmann wrote: > I made the measurements with my 'scope. The voltages and waveforms are > identical comparing DTR, RTS (also RXD), although I am surprised a little > that the pulses on DTR are as large as they are: 2.4V swing. Must be some > resistance in the supply to the drain. But the level is up at 11.6V, so > those 2.4V drops cannot matter. The signals on the RXD pin are -3.6 to > +8.2V for both the mfg. sw and sigrok. > > So no explanation yet, and hence no solution. Is there a way to examine > the serial parameters the mfg. sw uses? Perhaps the docs on the protocol > are in error. > > On Fri, Dec 29, 2017 at 9:17 AM, Denis Heidtmann < > denis.heidtm...@gmail.com> wrote: > >> I will make those measurements, but I am doubtful it will show anything. >> The schematic I have shows DTR to be the collector and RTS to be the low >> end of the emitter resistor of the output NPN. I did see solid pulses on >> the emitter with sigrok. But perhaps DTR and/or RTS are pulsed when they >> should not be. It is too bad my 'scope has limited record length and no >> way to store the data off the 'scope. >> >> On Thu, Dec 28, 2017 at 11:42 PM, Russell Senior < >> russ...@personaltelco.net> wrote: >> >>> Have you measured the voltages on DTR and RTS during the runs? >>> >>> Try it with sigrok and with the vendor software and see if there is a >>> difference in those values. >>> >>> On Thu, Dec 28, 2017 at 9:51 PM, Denis Heidtmann >>> wrote: >>> > This saga continues. >>> > >>> > On the laptop with a usb-serial adapter I got to the point where the >>> > commands: >>> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --show >>> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --scan >>> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --samples 10 >>> > >>> > behave as expected except the last one returns no data. I was advised >>> to >>> > try using these same commands on the desktop which has an RS232 port, >>> thus >>> > removing the usb-serial adapter from the picture. Good idea. >>> > >>> > After just guessing what serial port to use, I run the following >>> command: >>> > >>> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --scan >>> > The following devices were found: >>> > mastech-mas345 - MASTECH MAS345 with 1 channel: P1 >>> > >>> > This is the same response I got on the laptop. >>> > >>> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --show >>> > mastech-mas345 - MASTECH MAS345 with 1 channel: P1 >>> > Supported driver options: >>> > conn >>> > serialcomm >>> > Supported configuration options: >>> > >>> > This is the same response I got on the laptop. >>> > >>> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --samples 10 >>> > >>> > [no response except the usual ~10 second delay] >>> > >>> > This is the same response I got on the laptop. RATS! >>> > >>> > This eliminates the usb-serial device from the picture. >>> > >>> > Recall that when running --samples 10 command on the laptop I was able >>> to >>> > detect pulses on the serial line consistent (in a general sense) with a >>> > response from the dmm. Also recall that running the mfg. sw under >>> windows >>> > on the desktop showed flawless communication. >>> > >>> > finally, I report: >>> > stty -F /dev/ttyS0 -a speed 600 baud; rows 0; columns 0; line = 0; >>> > intr = ; quit = ; erase = ; kill = ; eof = >>> > ; >>> > eol = ; eol2 = ; swtch = ; start = ; stop = >>> > ; >>> > susp = ; rprnt = ; werase = ; lnext = ; >>> > discard = ; min = 0; time = 0; >>> > -parenb -parodd -cmspar cs7 hupcl cstopb cread clocal -crtscts >>> > -ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl >>> -ixon >>> > -ixoff >>> > -iuclc -ixany -imaxbel -iutf8 >>> > -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 >>> bs0 >>> > vt0 ff0 >>> > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase >>> -tostop >>> > -echoprt >>> > -echoctl -echoke -flusho -extproc >>> > >>> > And the protocol is reported to be: >>> > >>> > 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. >>> > >>> > Any suggestions as to where to go from here? >>> > >>> > Thanks, >>> > -Denis >>> > ___ >>> > PLUG mailing list >>> > PLUG@pdxlinux.org >>> > http://lists.pdxlinux.org/mailman/listinfo/plug >>> ___ >>> PLUG maili
Re: [PLUG] serial communication with dmm (was com port in guest to usb in host (virtual box))
Tomas, Thanks so much for the offer. I will look at the Bitscope website to see if it would help. -Denis On Fri, Dec 29, 2017 at 3:36 PM, Tomas Kuchta wrote: > I have one of those simple Bitscope scopes/analysers for slow RPi type > interface hacking it might be the right tool for the job and it runs on > Linux. > > Would that help? Do you want to borrow it? > > Check the Bitscope website for details, but it is good enough for serial > ports. Perhaps even decoding it. > > Tomas > > On Dec 29, 2017 2:44 PM, "Denis Heidtmann" > wrote: > > > I made the measurements with my 'scope. The voltages and waveforms are > > identical comparing DTR, RTS (also RXD), although I am surprised a > little > > that the pulses on DTR are as large as they are: 2.4V swing. Must be > some > > resistance in the supply to the drain. But the level is up at 11.6V, so > > those 2.4V drops cannot matter. The signals on the RXD pin are -3.6 to > > +8.2V for both the mfg. sw and sigrok. > > > > So no explanation yet, and hence no solution. Is there a way to examine > > the serial parameters the mfg. sw uses? Perhaps the docs on the protocol > > are in error. > > > > On Fri, Dec 29, 2017 at 9:17 AM, Denis Heidtmann < > > denis.heidtm...@gmail.com> > > wrote: > > > > > I will make those measurements, but I am doubtful it will show > anything. > > > The schematic I have shows DTR to be the collector and RTS to be the > low > > > end of the emitter resistor of the output NPN. I did see solid pulses > on > > > the emitter with sigrok. But perhaps DTR and/or RTS are pulsed when > they > > > should not be. It is too bad my 'scope has limited record length and > no > > > way to store the data off the 'scope. > > > > > > On Thu, Dec 28, 2017 at 11:42 PM, Russell Senior < > > > russ...@personaltelco.net> wrote: > > > > > >> Have you measured the voltages on DTR and RTS during the runs? > > >> > > >> Try it with sigrok and with the vendor software and see if there is a > > >> difference in those values. > > >> > > >> On Thu, Dec 28, 2017 at 9:51 PM, Denis Heidtmann > > >> wrote: > > >> > This saga continues. > > >> > > > >> > On the laptop with a usb-serial adapter I got to the point where the > > >> > commands: > > >> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --show > > >> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --scan > > >> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --samples 10 > > >> > > > >> > behave as expected except the last one returns no data. I was > advised > > >> to > > >> > try using these same commands on the desktop which has an RS232 > port, > > >> thus > > >> > removing the usb-serial adapter from the picture. Good idea. > > >> > > > >> > After just guessing what serial port to use, I run the following > > >> command: > > >> > > > >> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --scan > > >> > The following devices were found: > > >> > mastech-mas345 - MASTECH MAS345 with 1 channel: P1 > > >> > > > >> > This is the same response I got on the laptop. > > >> > > > >> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --show > > >> > mastech-mas345 - MASTECH MAS345 with 1 channel: P1 > > >> > Supported driver options: > > >> > conn > > >> > serialcomm > > >> > Supported configuration options: > > >> > > > >> > This is the same response I got on the laptop. > > >> > > > >> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --samples 10 > > >> > > > >> > [no response except the usual ~10 second delay] > > >> > > > >> > This is the same response I got on the laptop. RATS! > > >> > > > >> > This eliminates the usb-serial device from the picture. > > >> > > > >> > Recall that when running --samples 10 command on the laptop I was > able > > >> to > > >> > detect pulses on the serial line consistent (in a general sense) > with > > a > > >> > response from the dmm. Also recall that running the mfg. sw under > > >> windows > > >> > on the desktop showed flawless communication. > > >> > > > >> > finally, I report: > > >> > stty -F /dev/ttyS0 -a speed 600 baud; rows 0; columns 0; line = 0; > > >> > intr = ; quit = ; erase = ; kill = ; > eof = > > >> > ; > > >> > eol = ; eol2 = ; swtch = ; start = ; > stop > > = > > >> > ; > > >> > susp = ; rprnt = ; werase = ; lnext = ; > > >> > discard = ; min = 0; time = 0; > > >> > -parenb -parodd -cmspar cs7 hupcl cstopb cread clocal -crtscts > > >> > -ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl > > -ixon > > >> > -ixoff > > >> > -iuclc -ixany -imaxbel -iutf8 > > >> > -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 > tab0 > > >> bs0 > > >> > vt0 ff0 > > >> > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase > > -tostop > > >> > -echoprt > > >> > -echoctl -echoke -flusho -extproc > > >> > > > >> > And the protocol is reported to be: > > >> > > > >> > data format: 7n2 at 600 baud (7 bits, no parity, 2 stop bits). > > >> > Control lines: > > >> >DTR and RTS lines are
Re: [PLUG] serial communication with dmm (was com port in guest to usb in host (virtual box))
I have one of those simple Bitscope scopes/analysers for slow RPi type interface hacking it might be the right tool for the job and it runs on Linux. Would that help? Do you want to borrow it? Check the Bitscope website for details, but it is good enough for serial ports. Perhaps even decoding it. Tomas On Dec 29, 2017 2:44 PM, "Denis Heidtmann" wrote: > I made the measurements with my 'scope. The voltages and waveforms are > identical comparing DTR, RTS (also RXD), although I am surprised a little > that the pulses on DTR are as large as they are: 2.4V swing. Must be some > resistance in the supply to the drain. But the level is up at 11.6V, so > those 2.4V drops cannot matter. The signals on the RXD pin are -3.6 to > +8.2V for both the mfg. sw and sigrok. > > So no explanation yet, and hence no solution. Is there a way to examine > the serial parameters the mfg. sw uses? Perhaps the docs on the protocol > are in error. > > On Fri, Dec 29, 2017 at 9:17 AM, Denis Heidtmann < > denis.heidtm...@gmail.com> > wrote: > > > I will make those measurements, but I am doubtful it will show anything. > > The schematic I have shows DTR to be the collector and RTS to be the low > > end of the emitter resistor of the output NPN. I did see solid pulses on > > the emitter with sigrok. But perhaps DTR and/or RTS are pulsed when they > > should not be. It is too bad my 'scope has limited record length and no > > way to store the data off the 'scope. > > > > On Thu, Dec 28, 2017 at 11:42 PM, Russell Senior < > > russ...@personaltelco.net> wrote: > > > >> Have you measured the voltages on DTR and RTS during the runs? > >> > >> Try it with sigrok and with the vendor software and see if there is a > >> difference in those values. > >> > >> On Thu, Dec 28, 2017 at 9:51 PM, Denis Heidtmann > >> wrote: > >> > This saga continues. > >> > > >> > On the laptop with a usb-serial adapter I got to the point where the > >> > commands: > >> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --show > >> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --scan > >> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --samples 10 > >> > > >> > behave as expected except the last one returns no data. I was advised > >> to > >> > try using these same commands on the desktop which has an RS232 port, > >> thus > >> > removing the usb-serial adapter from the picture. Good idea. > >> > > >> > After just guessing what serial port to use, I run the following > >> command: > >> > > >> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --scan > >> > The following devices were found: > >> > mastech-mas345 - MASTECH MAS345 with 1 channel: P1 > >> > > >> > This is the same response I got on the laptop. > >> > > >> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --show > >> > mastech-mas345 - MASTECH MAS345 with 1 channel: P1 > >> > Supported driver options: > >> > conn > >> > serialcomm > >> > Supported configuration options: > >> > > >> > This is the same response I got on the laptop. > >> > > >> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --samples 10 > >> > > >> > [no response except the usual ~10 second delay] > >> > > >> > This is the same response I got on the laptop. RATS! > >> > > >> > This eliminates the usb-serial device from the picture. > >> > > >> > Recall that when running --samples 10 command on the laptop I was able > >> to > >> > detect pulses on the serial line consistent (in a general sense) with > a > >> > response from the dmm. Also recall that running the mfg. sw under > >> windows > >> > on the desktop showed flawless communication. > >> > > >> > finally, I report: > >> > stty -F /dev/ttyS0 -a speed 600 baud; rows 0; columns 0; line = 0; > >> > intr = ; quit = ; erase = ; kill = ; eof = > >> > ; > >> > eol = ; eol2 = ; swtch = ; start = ; stop > = > >> > ; > >> > susp = ; rprnt = ; werase = ; lnext = ; > >> > discard = ; min = 0; time = 0; > >> > -parenb -parodd -cmspar cs7 hupcl cstopb cread clocal -crtscts > >> > -ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl > -ixon > >> > -ixoff > >> > -iuclc -ixany -imaxbel -iutf8 > >> > -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 > >> bs0 > >> > vt0 ff0 > >> > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase > -tostop > >> > -echoprt > >> > -echoctl -echoke -flusho -extproc > >> > > >> > And the protocol is reported to be: > >> > > >> > 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. > >> > > >> > Any suggestions as to where to go from here? > >> > > >> > Thanks, > >> > -Denis > >> > ___ > >> > PLUG mailing list > >> > PLUG@pdxlinux.org > >> > http://lists.pdxlinux.org/mailman/listinfo/plu
Re: [PLUG] serial communication with dmm (was com port in guest to usb in host (virtual box))
I made the measurements with my 'scope. The voltages and waveforms are identical comparing DTR, RTS (also RXD), although I am surprised a little that the pulses on DTR are as large as they are: 2.4V swing. Must be some resistance in the supply to the drain. But the level is up at 11.6V, so those 2.4V drops cannot matter. The signals on the RXD pin are -3.6 to +8.2V for both the mfg. sw and sigrok. So no explanation yet, and hence no solution. Is there a way to examine the serial parameters the mfg. sw uses? Perhaps the docs on the protocol are in error. On Fri, Dec 29, 2017 at 9:17 AM, Denis Heidtmann wrote: > I will make those measurements, but I am doubtful it will show anything. > The schematic I have shows DTR to be the collector and RTS to be the low > end of the emitter resistor of the output NPN. I did see solid pulses on > the emitter with sigrok. But perhaps DTR and/or RTS are pulsed when they > should not be. It is too bad my 'scope has limited record length and no > way to store the data off the 'scope. > > On Thu, Dec 28, 2017 at 11:42 PM, Russell Senior < > russ...@personaltelco.net> wrote: > >> Have you measured the voltages on DTR and RTS during the runs? >> >> Try it with sigrok and with the vendor software and see if there is a >> difference in those values. >> >> On Thu, Dec 28, 2017 at 9:51 PM, Denis Heidtmann >> wrote: >> > This saga continues. >> > >> > On the laptop with a usb-serial adapter I got to the point where the >> > commands: >> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --show >> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --scan >> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --samples 10 >> > >> > behave as expected except the last one returns no data. I was advised >> to >> > try using these same commands on the desktop which has an RS232 port, >> thus >> > removing the usb-serial adapter from the picture. Good idea. >> > >> > After just guessing what serial port to use, I run the following >> command: >> > >> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --scan >> > The following devices were found: >> > mastech-mas345 - MASTECH MAS345 with 1 channel: P1 >> > >> > This is the same response I got on the laptop. >> > >> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --show >> > mastech-mas345 - MASTECH MAS345 with 1 channel: P1 >> > Supported driver options: >> > conn >> > serialcomm >> > Supported configuration options: >> > >> > This is the same response I got on the laptop. >> > >> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --samples 10 >> > >> > [no response except the usual ~10 second delay] >> > >> > This is the same response I got on the laptop. RATS! >> > >> > This eliminates the usb-serial device from the picture. >> > >> > Recall that when running --samples 10 command on the laptop I was able >> to >> > detect pulses on the serial line consistent (in a general sense) with a >> > response from the dmm. Also recall that running the mfg. sw under >> windows >> > on the desktop showed flawless communication. >> > >> > finally, I report: >> > stty -F /dev/ttyS0 -a speed 600 baud; rows 0; columns 0; line = 0; >> > intr = ; quit = ; erase = ; kill = ; eof = >> > ; >> > eol = ; eol2 = ; swtch = ; start = ; stop = >> > ; >> > susp = ; rprnt = ; werase = ; lnext = ; >> > discard = ; min = 0; time = 0; >> > -parenb -parodd -cmspar cs7 hupcl cstopb cread clocal -crtscts >> > -ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon >> > -ixoff >> > -iuclc -ixany -imaxbel -iutf8 >> > -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 >> bs0 >> > vt0 ff0 >> > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop >> > -echoprt >> > -echoctl -echoke -flusho -extproc >> > >> > And the protocol is reported to be: >> > >> > 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. >> > >> > Any suggestions as to where to go from here? >> > >> > Thanks, >> > -Denis >> > ___ >> > 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
Re: [PLUG] serial communication with dmm (was com port in guest to usb in host (virtual box))
I will make those measurements, but I am doubtful it will show anything. The schematic I have shows DTR to be the collector and RTS to be the low end of the emitter resistor of the output NPN. I did see solid pulses on the emitter with sigrok. But perhaps DTR and/or RTS are pulsed when they should not be. It is too bad my 'scope has limited record length and no way to store the data off the 'scope. On Thu, Dec 28, 2017 at 11:42 PM, Russell Senior wrote: > Have you measured the voltages on DTR and RTS during the runs? > > Try it with sigrok and with the vendor software and see if there is a > difference in those values. > > On Thu, Dec 28, 2017 at 9:51 PM, Denis Heidtmann > wrote: > > This saga continues. > > > > On the laptop with a usb-serial adapter I got to the point where the > > commands: > > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --show > > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --scan > > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --samples 10 > > > > behave as expected except the last one returns no data. I was advised to > > try using these same commands on the desktop which has an RS232 port, > thus > > removing the usb-serial adapter from the picture. Good idea. > > > > After just guessing what serial port to use, I run the following command: > > > > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --scan > > The following devices were found: > > mastech-mas345 - MASTECH MAS345 with 1 channel: P1 > > > > This is the same response I got on the laptop. > > > > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --show > > mastech-mas345 - MASTECH MAS345 with 1 channel: P1 > > Supported driver options: > > conn > > serialcomm > > Supported configuration options: > > > > This is the same response I got on the laptop. > > > > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --samples 10 > > > > [no response except the usual ~10 second delay] > > > > This is the same response I got on the laptop. RATS! > > > > This eliminates the usb-serial device from the picture. > > > > Recall that when running --samples 10 command on the laptop I was able to > > detect pulses on the serial line consistent (in a general sense) with a > > response from the dmm. Also recall that running the mfg. sw under > windows > > on the desktop showed flawless communication. > > > > finally, I report: > > stty -F /dev/ttyS0 -a speed 600 baud; rows 0; columns 0; line = 0; > > intr = ; quit = ; erase = ; kill = ; eof = > > ; > > eol = ; eol2 = ; swtch = ; start = ; stop = > > ; > > susp = ; rprnt = ; werase = ; lnext = ; > > discard = ; min = 0; time = 0; > > -parenb -parodd -cmspar cs7 hupcl cstopb cread clocal -crtscts > > -ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon > > -ixoff > > -iuclc -ixany -imaxbel -iutf8 > > -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 > > vt0 ff0 > > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > > -echoprt > > -echoctl -echoke -flusho -extproc > > > > And the protocol is reported to be: > > > > 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. > > > > Any suggestions as to where to go from here? > > > > Thanks, > > -Denis > > ___ > > 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
Re: [PLUG] serial communication with dmm (was com port in guest to usb in host (virtual box))
Have you measured the voltages on DTR and RTS during the runs? Try it with sigrok and with the vendor software and see if there is a difference in those values. On Thu, Dec 28, 2017 at 9:51 PM, Denis Heidtmann wrote: > This saga continues. > > On the laptop with a usb-serial adapter I got to the point where the > commands: > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --show > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --scan > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --samples 10 > > behave as expected except the last one returns no data. I was advised to > try using these same commands on the desktop which has an RS232 port, thus > removing the usb-serial adapter from the picture. Good idea. > > After just guessing what serial port to use, I run the following command: > > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --scan > The following devices were found: > mastech-mas345 - MASTECH MAS345 with 1 channel: P1 > > This is the same response I got on the laptop. > > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --show > mastech-mas345 - MASTECH MAS345 with 1 channel: P1 > Supported driver options: > conn > serialcomm > Supported configuration options: > > This is the same response I got on the laptop. > > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --samples 10 > > [no response except the usual ~10 second delay] > > This is the same response I got on the laptop. RATS! > > This eliminates the usb-serial device from the picture. > > Recall that when running --samples 10 command on the laptop I was able to > detect pulses on the serial line consistent (in a general sense) with a > response from the dmm. Also recall that running the mfg. sw under windows > on the desktop showed flawless communication. > > finally, I report: > stty -F /dev/ttyS0 -a speed 600 baud; rows 0; columns 0; line = 0; > intr = ; quit = ; erase = ; kill = ; eof = > ; > eol = ; eol2 = ; swtch = ; start = ; stop = > ; > susp = ; rprnt = ; werase = ; lnext = ; > discard = ; min = 0; time = 0; > -parenb -parodd -cmspar cs7 hupcl cstopb cread clocal -crtscts > -ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon > -ixoff > -iuclc -ixany -imaxbel -iutf8 > -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 > vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt > -echoctl -echoke -flusho -extproc > > And the protocol is reported to be: > > 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. > > Any suggestions as to where to go from here? > > Thanks, > -Denis > ___ > 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
